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ABSTRACT 


The  objective  of  this  capstone  project  was  to  build  a  simulated  system  using  the  Joint 
Capabilities  Integration  and  Development  System/Defense  Acquisition  System 
(JCIDS/DAS)  process  to  gain  insight  into  JCIDS/DAS  as  it  relates  to  unmanned  robotics 
systems.  JCIDS  and  DAS  are  the  Department  of  Defense’s  procedures  and  guidelines  for 
acquiring  military  programs.  Using  JCIDS/DAS  and  system  engineering  (SE) 
methodology,  the  team  developed  a  radiological  clearance  system  (RCS)  and  an 
unmanned  ground  vehicle  (UGV)  using  LEGO  MINSTORMS.  The  UGV  was  named  the 
Threat  Exposure  and  Clearing  Hardware  Manipulated  Autonomously  or  Networked 
(TECHMAN).  The  team  researched  UGVs,  software  platforms  and  the  JCIDS  /DAS 
regulations  to  tailor  an  SE  approach  in  designing  and  building  the  TECHMAN  robot, 
starting  with  the  mission  needs  and  requirements  followed  by  system  architecture 
development.  The  team  tested  and  evaluated  two  TECHMAN  systems.  One  system  was 
teleoperated  and  the  other  was  autonomous.  The  team  compared  the  test  results  and  other 
system  attributes  of  the  two  platforms.  The  knowledge  gained  from  the  project  results 
was  used  to  provide  insight  into  the  JCIDS/DAS  process  with  regard  to  procurement  of 
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EXECUTIVE  SUMMARY 


Unmanned  systems  (UMSs)  have  become  an  integral  part  of  U.S.  military 
operations  and  have  proven  themselves  effective  force  multipliers  by  providing  the 
warfighter  with  enhanced  capabilities  while  reducing  their  exposure  to  potentially 
dangerous  environments.  By  the  end  of  2010,  the  DOD  had  deployed  nearly  8,000 
unmanned  ground  vehicles  (UGVs)  (Office  of  the  Under  Secretary  of  Defense  for 
Acquisition,  Technology  and  Logistics  et  al.  2006,  5).  By  the  end  of  201 1,  UGVs  had 
participated  in  over  125,000  missions  and  defeated  over  1 1,000  improvised  explosive 
devices  (Department  of  Defense  2011,  23). 

At  present,  most  UGV  systems  in  the  U.S.  military  inventory  were  fielded  under 
various  rapid  fielding  initiatives  in  lieu  of  the  full  Joint  Capabilities  Integration 
Development  System  (JCIDS)  process  and  Defense  Acquisition  System  (DAS).  Although 
there  may  be  many  reasons  for  this,  the  team’s  research  indicated  that  the  most  prominent 
reason  is  the  need  to  rapidly  deploy  new  capability  to  warfighters  due  to  the  operational 
demands  of  Operation  Iraqi  Freedom  (OIF)  /  Operation  New  Dawn  (OND),  and 
Operation  Enduring  Freedom  (OEF).  However,  a  secondary  reason  why  the  JCIDS/DAS 
process  is  avoided  is  the  added  cost,  time,  and  requirements  it  imposes  on  the  acquisition 
effort.  Maintainability,  usability,  and  making  sure  that  the  system  provides  a  new 
capability  rather  than  duplicating  an  existing  one  are  all  examined  by  JCIDS/DAS,  but 
can  be  omitted  under  rapid  fielding.  Following  the  JCIDS/DAS  process  forces  system 
designers  to  plan  for  these  additional  design  factors  that  some  rapid  fielding  efforts  have 
omitted.  Thus,  there  is  a  tradeoff  between  the  short-term  gains  of  rapid  fielding  and  long¬ 
term  design  robustness  gains  that  JCIDS/DAS  provides. 

Project  TECHMAN  is  a  research  project  of  the  difficulties  and  benefits 
encountered  by  UGV  systems  as  they  move  through  the  JCIDS/DAS  in  lieu  of  using  a 
rapid  fielding  initiative.  To  test  this,  the  TECHMAN  team  created  two  Remote  Clearance 
Vehicles  under  simulated  JCIDS/DAS  conditions.  The  first,  the  Teleoperated  Clearance 
Vehicle  (TCV),  performs  clearance  operations  while  being  controlled  remotely  by  an 


operator.  The  other,  the  Autonomous  Clearance  Vehicle  (ACV),  perfonns  clearance 
operations  autonomously.  Both  vehicles  enter  a  target  area  to  pick  up  small  vials 
representing  hazardous  targets,  and  then  they  return  the  vials  for  safe  disposal  by  an 
operator. 

The  team  followed  a  simulated  version  of  the  JCIDS/DAS  process  by  creating 
work  items  such  as  a  capability  needs  assessment,  analysis  of  alternatives,  requirements 
analysis,  system  hardware  and  software  architectures,  system  design,  and  a  test  and 
evaluation  plan.  The  team  also  met  at  Aberdeen  Proving  Ground,  Maryland,  to  carry  out 
formal  system  tests  on  the  two  TECHMAN  prototypes. 

The  TECHMAN  prototypes  successfully  completed  testing.  The  TCV  was  found 
to  be  more  accurate  at  clearing  vials;  however,  the  TCV  required  the  operator’s  full 
attention.  The  TCV  also  required  the  operator  have  line  of  sight  of  the  clearing  area.  The 
ACV  was  not  as  accurate  at  clearing  the  vials  as  the  TCV  but  still  managed  to  eventually 
clear  all  of  the  vials.  The  ACV  mission  time  was  longer  than  the  TCV  but  the  ACV  did 
not  require  the  full  attention  of  the  operator. 

The  project  showed  the  validity  of  the  JCIDS/DAS  process  throughout  the  design 
and  build  of  the  TECHMAN  systems.  If  the  project  continued,  the  JCIDS/DAS  process 
would  help  the  team  mature  the  design  and  correct  the  issues  found  during  the  evaluation 
and  ensure  the  system  to  be  fielded  meets  the  user  need  while  being  reliable, 
maintainable,  and  supportable.  These  artifacts  are  discussed  in  detail  in  this  report. 
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I.  INTRODUCTION  AND  BACKGROUND 


A.  INTRODUCTION 

This  capstone  report  has  been  developed  by  a  team  of  students  at  the  Naval 
Postgraduate  School  (NPS)  in  the  Master  of  Science  in  Systems  Engineering  (MSSE)  and 
Master  of  Science  in  Engineering  Systems  (MSES)  distance  learning  cohort  3 1 1-1420. 
The  team  used  the  Joint  Capabilities  Integration  and  Development  System  (JCIDS),  the 
Defense  Acquisition  System  (DAS),  and  a  System  Engineering  (SE)  approach  to  develop 
a  Radiological  Clearance  System  (RCS)  and  build  an  unmanned  ground  vehicle  (UGV) 
using  the  LEGO  MINSTORMS  EV3  platform.  The  team  named  the  UGV  the  Threat 
Exposure  and  Clearing  Hardware  Manipulated  Autonomously  or  Networked 
(TECHMAN).  Although  the  RCS  only  simulates  a  real  military  system,  its  development 
during  this  project  followed  the  processes  contained  in  the  JCIDS  and  DAS.  Over  the 
nine  months  of  the  project  the  team  researched  UGVs,  JCIDS/DAS,  and  software 
development  for  the  TECHMAN.  Based  on  the  JCIDS  and  DAS  regulations,  the  team 
tailored  an  SE  process  to  develop  and  built  the  TECHMAN  robot  followed  by  test  and 
evaluation.  The  team  evaluated  the  test  data  and  system  attributes  to  determine  each 
system’s  effectiveness. 

B.  BACKGROUND 

Throughout  the  past  decade,  umnanned  systems  (UMSs)  have  become  an  integral 
part  of  United  States  military  operations.  UMSs  have  proven  to  be  effective  force 
multipliers,  providing  the  warfighter  with  enhanced  capabilities  while  reducing  their 
exposure  to  potentially  dangerous  environments.  The  majority  of  currently  fielded  UMSs 
are  in  response  to  capability  gaps  identified  by  the  warfighter’s  need  for  heightened 
intelligence,  surveillance,  and  reconnaissance  (ISR)  as  well  as  chemical,  biological, 
radiological  and  nuclear,  explosive  (CBRNE)  threats  (Department  of  Defense  2011,  22). 
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The  ongoing  operations  of  the  Department  of  Defense  (DOD)  in  Iraq  and 
Afghanistan  have  led  to  the  deployment  of  thousands  of  UMSs.  By  the  end  of  2006,  the 
DOD  had  deployed  nearly  4,000  UGVs  (Office  of  the  Under  Secretary  of  Defense  for 
Acquisition,  Technology  and  Logistics  (OUSD(AT&L))  et  al.  2006,  5)  with  numbers 
reaching  approximately  8,000  by  the  end  of  2010.  At  this  point,  UGVs  alone  had 
participated  in  over  125,000  missions  and  defeating  over  1 1,000  improvised  explosive 
devices  (IEDs)  (Department  of  Defense  2011,  23).  UMSs  have  become  a  tremendous 
asset  for  modern  U.S.  forces,  extending  areas  of  operation,  and  saving  military  lives  by 
removing  the  warfighter  from  dangerous  situations. 

According  to  the  Unmanned  Systems  Integrated  Roadmap,  UMSs  “are  a  powered 
physical  system  with  (optionally)  no  human  operator  aboard  the  principal  platform, 
which  can  act  remotely  to  accomplish  assigned  tasks.  UGS  may  be  mobile  or  stationary, 
can  be  smart  learning  and  self-adaptive,  and  include  all  associated  supporting 
components  such  as  operator  control  units  (OCU)”  (Department  of  Defense  2013,  6). 
When  operating  in  hazardous,  unfamiliar  environments,  it  is  preferable  for  warfighters  to 
investigate  potentially  dangerous  objects  via  some  remote  means.  The  utilization  of 
autonomous  or  teleoperated  UMSs  enables  the  development  of  techniques,  tactics  and 
procedures  (TTPs)  to  significantly  reduce  the  potential  of  injury  or  casualty  to  service 
members  from  hazardous  threats. 

Today,  modem  U.S.  forces  have  been  able  to  reduce  manning  requirements, 

extend  operational  areas,  and  save  military  lives  by  adding  UMSs  to  the  force  structure. 

Recent  advancements  in  UMSs  have  further  subdivided  by  their  ability  to  accomplish 

assigned  tasks  with  or  without  continuous  input  from  their  operators,  referring  to  the  level 

of  autonomy  the  said  system  is  capable.  The  majority  of  UGVs  currently  fielded  by  the 

DOD,  such  as  the  man  transportable  robotics  system  (MTRS),  Dragon  Runner  10,  and 

MarcBot  IV-N,  are  only  capable  of  being  directly  teleoperated  by  a  human.  There  are  a 

number  of  limited  UGVs  capable  of  semi-autonomous  operation,  such  as  the  Mobile 

Detection  Assessment  Response  System  (MDARS).  However,  this  limited  autonomy 

only  allows  for  completing  relatively  simplistic  or  repetitive  actions  (OUSD(AT&L)). 

Enabling  UMSs  with  greater  levels  of  autonomy  is  currently  the  subject  of  extensive 
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research  and  development  by  the  DOD  and  its  industry  partners  (Robotic  Systems  Joint 
Project  Office  (RS  JPO)  2011,  22). 

Achieving  improved  system,  sensor,  and  analytical  autonomy  of  UMSs  would 
allow  for  advanced  teaming  of  manned  and  unmanned  assets  while  simultaneously 
reducing  the  manpower  requirements  for  operating  UMSs.  This  would  lead  to  decreasing 
key  budgetary  cost  drivers  as  well  as  reducing  or  eliminating  the  exposure  of  human  lives 
to  dangerous  situations,  both  of  which  are  important  goals  for  the  DOD  (Department  of 
Defense  2013,  29).  As  new  generations  of  UMSs  are  developed,  it  is  likely  they  will  have 
the  ability  of  executing  operational  tasks  superior  to  what  humans  are  capable  of.  With 
the  advancement  of  umnanned  technology,  hazardous  tasks  will  be  able  to  be  perfonned 
remotely  with  limited  to  no  human  interaction.  Additionally,  the  capabilities  of  UMSs 
will  expand  as  improvements  are  made  to  sensor  technologies,  software  algorithms,  and 
artificial  intelligence  (Department  of  Defense  2013,  15). 

Although  the  deployment  of  UMSs  has  led  to  significant  success  in  protecting 
service  members  from  new  and  rapidly  evolving  threats  in  combat  zones,  the  majority  of 
these  systems  were  acquired  as  commercial-off-the-shelf  (COTS)  systems  using  rapid 
acquisition  methods  eschewing  the  traditional  DOD  acquisition  framework.  The 
proliferation  of  IEDs  resulted  in  Joint  Urgent  Operational  Needs  Statements  (JUONSs) 
and  Operational  Needs  States  (ONSs)  requesting  additional  solutions  to  combat  the 
enemy’s  use  of  unanticipated  weapons  and  tactics  (Baca  2012,  3).  DOD  organizations 
such  as  the  Army’s  Rapid  Equipping  Force  (REF)  were  able  to  mitigate  many  of  these 
new  capability  gaps  through  the  deployment  of  UMSs  funded  by  overseas  contingency 
operations  (OCO)  funds  (Baca  2012,  4). 

The  urgent  wartime  need  for  these  systems  prompted  by  the  JUONSs/ONSs,  the 
rapid  fielding  of  these  systems  allowed  the  DOD  to  combat  the  immediate  threat, 
however  these  acquisitions  did  not  follow  the  JCIDS/DAS  process  necessary  for  ensuring 
a  viable  long-term  solution.  By  circumventing  the  JCIDS/DAS  process,  a  functional 
needs  analysis  (FNA)  was  not  conducted  nor  was  proper  consideration  given  to  the 
doctrine,  organization,  training,  materiel,  leadership  and  education,  personnel,  and 
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facilities  (DOTMLPF)  aspects  of  these  systems  to  ensure  long  term  sustainability  (Baca 
2012,  4).  Additionally,  the  rapid  fielding  of  these  systems  without  the  coordination  of 
established  program  of  records  (POR)  resulted  in  a  fractured  state  causing  duplications  of 
effort,  integration  challenges  from  proprietary  designs,  and  extreme  costs  in  labor,  time, 
and  OCO  funding  (The  Industrial  College  of  the  Armed  Forces  2011,  14).  The  resultant 
systems  were  too  immature  in  tenns  of  reliability  and  supportability,  relying  heavily  on 
contractor  logistics  support,  which  is  unsustainable  (Department  of  Defense  2013,  93). 

For  sustained  operations,  a  more  systematic  approach  is  required  that  looks  at  all 
the  factors  involved  in  developing,  supporting,  and  maintaining  UMSs  through  the 
complete  product  life-cycle.  Systems  developers  must  establish  cost  effective,  long-term 
life-cycle  sustainment  strategies  capable  of  fulfilling  warfighter  requirements 
(Department  of  Defense  2013,  93).  Therefore,  the  team  applied  an  SE  approach  to  the 
development  of  two  UMSs  within  the  JCIDS/DAS  process  to  see  where  improvements 
can  be  achieved  in  the  process  and  the  systems  themselves. 

C.  LITERATURE  REVIEW 

The  capstone  team  perfonned  a  literature  review  with  the  intent  of  establishing  a 
foundation  of  knowledge  based  on  existing  publications  and  research  focused  on  the 
DOD’s  research,  development,  acquisition,  and  fielding  of  UMSs. 

The  Unmanned  Systems  Integrated  Roadmap,  a  biennial  publication  of  the  DOD, 
is  intended  to  communicate  the  unified  “vision  and  strategy  for  the  continued 
development,  production,  test,  training,  operation,  and  sustainment  of  unmanned  systems 
technology  across  the  DOD”  (Department  of  Defense  2013,  v).  These  reports  outline  the 
current  state  of  ongoing  DOD  efforts  related  to  air,  ground,  and  maritime  UMSs.  The 
TECHMAN  team  used  this  report  series  to  fonn  a  baseline  understanding  of  current  and 
planned  UMS  applications  within  the  DOD. 

The  Unmanned  Ground  Systems  Roadmap  is  published  by  the  Robotic  Systems 
Joint  Project  Office  (RS  JPO)  to  establish  their  short  and  long-term  goals  and  strategies 
relating  to  the  development  and  acquisition  of  unmanned  ground  systems  (Robotic 
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Systems  Joint  Project  Office  2011,  5).  This  report  provided  the  team  with  detailed 
information  on  specific  COTS  and  POR  UGVs  currently  fielded  by  the  DOD. 

COL  Glenn  Baca  conducted  a  research  project  for  the  United  States  Army  War 
College  titled  An  Analysis  ofU.S.  Army  Unmanned  Ground  Vehicle  Strategy.  Baca 
investigated  the  current  DOD  and  emerging  Army  strategies  related  to  UGVs  (Baca 
2012).  This  report  provided  the  team  with  initial  awareness  of  the  negative  long-term 
effects  associated  with  bypassing  the  JCIDS/DAS  process  in  favor  of  the  rapid  fielding 
process  to  supply  forces  with  UMSs. 

The  Defense  Science  Board  published  the  Task  Force  Report:  The  Role  of 
Autonomy  in  DOD  Systems.  This  report  contained  the  results  of  their  study  on  the 
operational  benefits,  capability,  technical  issues,  and  acquisition  issues  of  autonomy- 
related  plans  of  the  DOD  (Defense  Science  Board  2012,  5).  This  report  provided  the  team 
with  insight  into  the  current  challenges  and  technological  limitations  faced  by  the  DOD 
when  developing  autonomous  systems. 

The  team  also  utilized  the  paper  “Destruction  and  Creation”  by  Air  Force  COL 
John  Boyd.  In  this  seminal  paper,  Boyd  details  the  observe,  orient,  decide,  act  (OODA) 
strategy  used  by  decision  makers,  also  known  as  the  OODA  Loop  (Boyd  1976).  The 
TECHMAN  ACV’s  autonomous  decision  making  features  were  designed  to  model 
Boyd’s  OODA  Loop. 

D.  PROBLEM  STATEMENT 

The  DOD  has  received  increased  funding  and  support  for  the  development  of 
UMSs  due  to  their  usefulness  in  the  field,  however,  the  success  rate  for  meeting  cost, 
schedule,  performance,  and  supportability  objectives  for  development  and  fielding  UMSs 
in  the  Department  of  Defense  has,  in  general,  been  low.  Although  the  importance  of 
UMSs  will  continue  to  grow,  the  success  of  UMS  acquisition  projects  continues  to  be  a 
problem.  The  DOD  needs  to  identify  and  understand  the  reasons  behind  the  limited 
efficacy  of  the  current  JCIDS/DAS  in  terms  of  UMS  development  as  well  as  establish  a 
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strategy  to  address  these  shortcomings.  A  high  level  graphic  of  the  JCIDS/DAS  process  is 
shown  in  Figure  1 . 
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Figure  1.  High  Level  View  of  JCIDS  (from  CJCSI  2015) 


There  are  various  types  of  fielded  UMSs  that  have  duplicating  or  overlapping 
capabilities.  Due  to  the  rapid  need  for  these  systems  to  meet  present  wartime  demands, 
the  majority  of  these  systems  have  been  developed  without  the  benefits  of  going  through 
the  traditional  JCIDS/DAS  process.  The  rapid  fielding  process  lacks  many  of  the  aspects 
of  the  JCIDS/DAS  process.  The  primary  focus  during  development  has  been  meeting 
mission  operational  objectives.  This  rapid  development  process  has  been  performed  with 
weak  consideration  of  many  factors,  such  as:  affordability,  supportability,  life-cycle 
support,  reliability,  availability,  maintainability,  interoperability,  and  logistics.  This  has 
caused  long  term  problems  related  to  cost,  performance,  and  supportability  throughout 
the  life-cycle  of  UMSs.  While  this  approach  to  UMS  development  may  be  appropriate  for 
wartime  contingency  operations,  it  has  proven  to  be  inadequate  for  systems  that  are 
expected  to  perform  for  periods  of  long-term  sustained  operations. 
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The  solution  may  involve  finding  a  balance  in  merging  the  rapid  fielding  process 
with  the  JCIDS/DAS  process.  Whatever  the  solution  may  be,  as  long  as  acquirers  feel 
that  the  life-cycle  planning  required  by  JCIDS/DAS  regulations  are  incompatible  with 
rapid  acquisition,  support  problems  will  continue. 

E.  PROJECT  OBJECTIVES 

There  were  three  objectives  for  this  project.  The  main  objective  was  to  improve 
the  team  members’  understanding  of  the  SE  process  by  developing  an  actual  hands-on, 
end-to-end  system  using  the  SE  process  as  taught  by  NPS.  The  second  objective  was  for 
the  team  to  better  understand  what  is  required  to  design  and  develop  teleoperated  and 
autonomous  robotic  systems  within  the  context  of  the  JCIDS/DAS  process.  The  team  was 
specifically  interested  in  how  using  the  JCIDS/DAS  process  related  to  cost,  schedule, 
performance,  and  supportability  of  UGVs  and  a  comparison  of  the  two  systems.  The  third 
objective  was  to  support  development  of  NPS  CRUSER-supported  robotic  and  umnanned 
systems  graduate  teaching  material. 

F.  RESEARCH  QUESTIONS 

This  research  project  examined  the  use  of  LEGO  MINSTORMS  Robots  to 
simulate  the  remote  removal  of  hazardous  materials.  The  project  was  designed  to  answer 
the  following  questions: 

1.  How  well  does  the  JCIDS/DAS  process  support  the  acquisition  and 
development  of  UGVs? 

2.  What  SE  approaches,  tools,  and  techniques  are  critical  to  successful  UGV 
projects? 

3.  Given  a  set  of  perfonnance  and  suitability  requirements,  how  easy  is  it  to 
accurately  estimate  cost  and  schedule  for  UGV  projects  within  the 
JCIDS/DAS  process? 

4.  How  much  difference  is  there  in  the  effort  involved  with  developing 
teleoperated  systems  and  the  effort  involved  with  developing  autonomous 
systems? 
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5.  What  are  the  tradeoffs  in  sensors  and  computation  for  autonomous  and 
teleoperated  UGVs? 

6.  What  are  the  impacts  on  both  acquisition  and  mission  completion  when 
comparing  autonomous  and  teleoperated  UGVs? 

7.  How  much  of  a  difference  does  the  choice  of  software  engineering  approach 
make? 

G.  PROJECT  DESCRIPTION  AND  SCOPE 

The  team  used  the  scenario  that  ground  forces  need  a  capability  to  clear  terrain  of 
radiological  containers.  The  two  TECHMAN  variants  were  developed  to  meet  this 
capability  using  LEGO  MINSTORMS.  Figure  2  shows  the  operational  view  (OV-1).  The 
OV-1  illustrates  the  concept  of  operations  of  TECHMAN  that  is  the  groundwork  for  the 
design  reference  mission  (DRM).  The  UGV  clears  vials  from  the  search  area  by  being 
remotely  controlled  by  the  operator  or  being  autonomously  controlled  by  programed 
logical  algorithms  in  its  software.  The  UGV  mission  is  complete  once  the  vials  are 
removed  from  the  area  to  be  cleared  and  placed  in  the  corral.  Figure  3  is  the  context 
diagram  for  the  TECHMAN  system.  Data  and  information  flows  are  illustrated  between 
the  TECHMAN  and  various  supporting  and  supported  elements  of  the  system. 
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Figure  2.  Operational  View 


Figure  3.  Context  Diagram 
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H.  PROJECT  ASSUMPTIONS  AND  CONSTRAINTS 


1.  Assumptions 

The  team  members  assumed  the  roles  of  the  organizations  and  personnel  involved 
in  an  acquisition  program  up  to  milestone  (MS)  B.  This  drove  the  team  members  to  take 
different  roles  and  functions  throughout  the  JCIDS/DAS  process  which  include: 

•  the  user 

•  program  manager 

•  design  engineer 

•  system  builders 

•  independent  test  and  evaluation  team 

•  logistics  managers 

•  decision  authority 

•  software  developers 

•  technical  writers 

2.  Constraints 

The  main  constraint  of  the  system  development  was  using  the  LEGO 
MINDSTORMS  EV3  hardware  for  a  material  solution.  The  mechanical  strength  of  the 
Lego  system  is  inherently  weak  compared  with  actual  military  UGVs.  The  sensor 
systems  do  not  have  the  accuracy  or  range  typically  seen  with  UGVs  either.  The  Lego 
Mindstorms  systems  are  also  limited  to  the  terrain  they  are  able  to  traverse.  To  deal  with 
this  constraint  the  team  assumed  the  user  would  know  the  technology  limitations.  The 
top-level  user  need  is  a  very  realistic  need  derived  from  the  Unmanned  Systems  ICD. 
However,  the  lower  level  requirements  for  how  to  provide  that  capability  were  written 
with  the  constraints  of  Mindstorms  in  mind.  A  full  system  not  restricted  to  Mindstonns 
limitations  might  consider  a  more  capable  architecture  and  more  aggressive  system 
requirements. 
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Another  constraint  for  the  project  was  the  time  allotted  to  complete  all  of  the 
JCIDS/DAS  deliverables.  The  time  required  for  a  program  to  reach  MS  B  varies  but  is 
normally  much  more  than  nine  months.  To  address  this,  Team  TECHMAN  only 
developed  deliverables  that  contained  the  essence  of  the  JCIDS/DAS  process. 

The  last  constraint  was  that  the  team  members  were  limited  to  the  skills  and 
abilities  of  each  team  member.  Although  the  team  included  two  software  developers, 
neither  of  them  had  experience  working  in  either  of  the  two  special  purpose  software 
environments  created  specifically  for  programming  Mindstorms  devices. 

I.  APPROACH 

1.  System  Engineering  Process 

The  project  team  used  the  full  toolbox  of  systems  engineering  methods  to 
complete  the  TECHMAN  system.  The  team  identified  and  implemented  configuration 
management/source  control  solutions.  The  team  followed  the  JCIDS/DAS  process  to  MS 
B  in  developing  the  TECHMAN  system.  The  team  presented  briefings  that  supported  the 
essence  of  the  JCIDS/DAS  documents  for  milestones  A  and  B.  In  the  JCIDS  process, 
different  approaches  to  achieving  the  mission  are  considered  in  the  Analysis  of 
Alternatives.  The  selection  of  one  of  the  alternatives  occurs  at  Milestone  A.  Proposals  for 
systems  that  selected  from  the  proposed  alternatives  are  solicited  and  prototypes  are 
refined.  Milestone  B  represents  the  decision  to  formally  establish  the  Program  Office. 

The  team  used  the  Vee  model  of  systems  engineering,  shown  in  Figure  4,  as  the 
road  map  through  the  development  of  the  TECHMAN  system.  The  model  assisted  in: 

•  development  of  concept  of  operations 

•  defining  system  requirements 

•  allocating  sub-system  functions 

•  conducting  detailed  component  design 

•  updating  requirements  and  functions  to  fit  capabilities 
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•  implementing  hardware  and  software  solutions 

•  verification  and  validation  (component,  subsystem,  and  system  levels) 


Tim* 


Figure  4.  System  Engineering  Vee  (from  CSM  2007) 


In  addition,  the  team  used  recognized  Software  Engineering  methodologies  in 
creating  the  TECHMAN  Autonomous  Clearance  Vehicle  (ACV)  and  TECHMAN 
Teleoperated  Clearance  Vehicle  (TCV). 

a.  Initial  Research 

The  team  developed  the  problem  statement  and  reviewed  relevant  resources  to 
fully  understand  the  problems.  The  team  completed  an  analysis  of  alternatives  (AO  A). 
The  team  used  the  initial  capabilities  document  (ICD)  for  unmanned  systems  provided  by 
the  NPS  capstone  advisors.  Development  of  the  systems  engineering  management  plan 
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(SEMP)  began  in  the  initial  research  phase  and  included  initial  cost  and  schedule  goals 
along  with  risk  management. 


b.  Needs/Requirem  ents  A  nalysis 

The  ICD  for  unmanned  systems  provided  the  starting  point  for  determining  the 
user  capability  gap.  The  team  developed  a  DRM.  Operational  requirements  were 
developed  from  the  DRM.  These  requirements  were  documented  in  the  capability 
development  document  (ODD).  A  draft  ODD  was  created  for  MS  A  and  the  final  was 
completed  for  MS  B.  The  TECHMAN  system  requirements  were  developed  from  the 
ODD. 


c.  System  Design 

System  design  and  development  commenced  following  finalization  of 
requirements.  The  system  engineering  Vee  model  was  used  during  design  and 
development.  The  system  architecture  was  developed  and  tracked  throughout  the  design 
and  build  of  the  system.  A  life-cycle  cost  analysis  was  performed.  Documentation  was 
continually  updated  with  the  changes  in  the  system  design. 

d.  Test  and  Evaluation  (T&E) 

A  test  and  evaluation  plan  was  developed  to  support  system  assessment.  The  plan 
was  structured  to  ensure  that  the  testing  would  verify  if  the  requirements  were  met. 
Evaluation  of  test  results  assessed  UGV  capability  in  satisfying  system  requirements. 

e.  Milestone  B 

Once  the  test  and  evaluation  was  complete  all  documents  were  updated  to  support 
the  MS  B  decision.  The  ODD  was  updated  with  lessons  learned  during  the  pre -milestone 
B  research.  The  SEMP  was  updated  with  the  final  system  design  and  infonnation 
including  cost  and  risk.  The  results  of  the  project  were  briefed  covering  all  of  the  MS  B 
deliverables  and  updates  to  the  final  system  design  information  including  cost  and  risk. 
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2. 


Life-Cycle  Engineering 


The  team  used  JCIDS/DAS  to  engineer  a  life-cycle  plan  for  the  TECHMAN 
prototypes  throughout  their  lives  from  the  initial  need  to  system  disposal.  Due  to  the 
constraints  of  the  stopping  at  MS  B,  the  team  perfonned  many  parts  of  the  extended  life- 
cycle  (such  as  training  end  users  and  system  disposal)  as  a  planning  exercise  rather  than 
fully  carrying  out  the  plan. 

a.  Conceptual  /  Prelim  inary  Design 

In  the  conceptual  and  preliminary  design  phase  the  team  performed  an  analysis  of 
requirements  followed  by  the  system  functional  analysis  and  operational  analysis.  Once 
the  analysis  was  completed  the  team  developed  engineering  models  and  sub  systems 
prototypes. 

b.  Detail  Design  and  Development 

During  the  detailed  design  and  development  the  team  designed  a  base  vehicle 
platform.  Software  and  mission  packages  were  added  to  the  base  platfonn  to  produce  the 
TECHMAN  TCV  and  TECHMAN  ACV.  The  SE  VEE  and  system  architecture  were 
used  during  the  development  process  to  match  the  system  capabilities  with  the  user 
requirements.  The  system  maintenance  plan,  training,  and  logistical  support  were 
developed  in  conjunction  with  the  system  design.  The  final  part  of  the  design  and 
development  phase  was  the  developmental  test  and  evaluation. 

c.  Production  and/or  Construction 

The  production  phase  for  the  TECHMAN  was  done  for  planning  as  the  project 
stopped  at  MS  B.  The  plan  includes  production  of  system  components,  suppliers,  and 
operational  test  and  evaluation. 
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d.  Utilization  and  Support 

The  Production,  Utilization  and  Support  phases  for  the  TECHMAN  were  outside 
the  scope  of  the  project.  The  project  stopped  at  MS  B.  The  plan  for  utilization  and 
support  includes  supporting  the  system  while  in  operations,  change  management  to 
account  for  any  engineering  changes  and  phase-out  and  disposal. 

J.  ORGANIZATION  AND  MANAGEMENT 

1.  Team  TECHMAN  Organization 

The  organization  of  Team  TECHMAN  is  shown  in  Figure  5.  The  team  consisted 
of  five  members  with  one  team  lead  and  two  members  each  on  the  ACV  and  TCV  sub 
teams.  The  two  sub  teams  collaborated  on  the  base  design  of  the  system  but  worked 
independently  while  developing  the  control  software. 


Dr.  Paul  Shebalin 

Bonnie  Young 

Casey  Fillinger 

NPS  Advisors 

Team  Lead 

TCV  System  ACV  System 


Figure  5.  Team  TECHMAN  Organization 


2.  Team  TECHMAN  Management 

a.  Personnel  Management 

Except  for  the  T&E  session  at  Aberdeen  Proving  Ground,  the  TECHMAN  team 
mostly  worked  remotely  from  each  other.  The  team  had  weekly  integrated  product  team 
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(IPT)  meetings  to  discuss  project  progress,  cover  future  work,  track  and  assign  work 
items,  and  raise  issues  with  other  team  members.  During  the  IPT  meetings,  minutes  were 
taken  and  used  as  reference  notes.  The  master  schedule  was  used  to  track  progress  and 
ensure  tasks  and  deliverables  were  completed  in  a  timely  manner. 

b.  Project  Management 

Progress  on  the  project  was  tracked  using  the  Earned  Value  Management  (EVM) 
technique.  Under  EVM,  schedule  and  cost  estimates  were  developed,  then  percentage  of 
planned  expenditure  was  used  as  a  proxy  to  measure  the  teams  progress.  Every  week,  the 
team  reported  the  number  of  hours  worked  on  the  project.  Thus,  the  Budgeted  Cost  of 
Work  Scheduled  (BCWS)  could  be  compared  to  the  Budgeted  Cost  of  Work  Perfonned 
(BCWP).  When  multiplied  by  an  estimated  salary  and  added  to  the  estimated  fixed  costs 
(for  the  cost  of  the  equipment  and  the  cost  of  performing  testing),  the  team  could 
calculate  the  Actual  Cost  of  Work  Performed  (ACWP). 

Figure  6  shows  a  sample  EVM  chart  that  the  team  reported  during  Week  25.  The 
T&E  session  at  Aberdeen  Proving  Grounds  was  conducted  during  Week  24,  which 
accounts  for  the  spike  during  that  week.  Note  that  the  BCWP  and  BCWS  mostly  track 
with  each  other.  The  ACWP  is  lower  than  the  other  two  because  the  fixed  costs  (for  the 
kits  and  for  the  testing)  were  lower  than  we  estimated. 
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Figure  6.  Week  25  EVM  Status 


Three  primary  methods  were  used  in  project  reporting  including:  weekly 
meetings,  interim  progress  report  (IPR)/Milestone  briefings,  and  the  final  report.  Weekly 
meeting  progress  reports  were  briefed  to  the  NPS  advisors  during  the  scheduled  class 
hour.  These  reports  covered  completed  tasks,  upcoming  tasks,  device  progress,  and 
progress  on  program  deliverables.  This  final  report  is  a  consolidated  document  that 
covers  all  elements  of  the  project. 

The  three  IPR/Milestone  presentations  were  briefed  to  an  audience  from  NPS. 

The  first  IPR  briefing  doubled  as  the  MS  A  briefing  and  covered  the  Analysis  of 
Alternatives,  the  project  plan,  and  other  preliminary  information  expected  at  MS  A.  The 
second  IPR  was  a  formal  progress  where  we  discussed  the  design  of  the  UGVs  and 
showed  video  of  them  in  operation.  We  also  discussed  the  T&E  plan,  because  the  T&E 
event  was  held  the  following  week.  The  third  IPR  doubled  as  the  MS  B  briefing  and 
covered  the  design  and  the  T&E  results.  This  final  IPR  was  also  used  as  a  closeout  for  the 
class. 
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The  team  used  Microsoft  OneDrive  as  the  main  knowledge  management 
repository.  All  documentation  generated  by  the  TECHMAN  team  was  stored  in  OneDrive 
so  the  entire  team  could  access  it  and  work  on  it  simultaneously.  Versioned  “releases”  of 
key  documents  were  stored  in  folders  parallel  to  the  living  documents.  The  source  code, 
requirements,  and  issue  tracking  was  managed  through  Visual  Studio  Online  source 
control  tool.  The  source  code  could  be  accessed  using  a  locking  fde  access  model  and  the 
source  code  can  integrate  with  Eclipse.  Code  changes,  requirements,  and  issues/bugs 
were  all  “linked”  to  each  other. 
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II.  MISSION  NEED  AND  REQUIREMENTS 


A.  CONCEPT  OF  OPERATIONS 

The  system  engineer  is  responsible  for  the  development  of  the  complete  system 
from  the  statement  of  the  stakeholders  needs  through  system  design,  development, 
deployment,  and  retirement.  During  this  process,  the  system  engineers  are  involved  in  the 
definition  of  the  systems  concepts  of  operations  (CONOPS),  which  spell  out  how  the 
system  will  operate  to  accomplish  its  mission.  The  PM  will  use  available  resources  to 
accomplish  its  roles,  missions,  and  functions.  The  CONOPS  is  designed  to  give  an 
overall  picture  of  the  operations  and  describes  system  characteristics  in  a  fashion  to 
describe  how  resources  will  be  organized  to  solve  an  emerging  military  problem  (CJCSI, 
2015). 

According  to  Frittman  and  Edson,  the  CONOPS  has  the  potential  to  add  value 
throughout  the  acquisition  life-cycle  but  is  often  underutilized.  They  point  out  that, 
although  many  in  the  acquisition  community  believe  the  CONOPS  is  critical  to  system 
success,  many  programs  do  not  develop  a  CONOPS  until  after  the  requirements  are 
written,  after  the  system  is  developed,  or  sometimes  not  at  all  (Edson  and  Frittman  2010). 
The  TECHMAN  team  recognized  the  importance  of  developing  a  high  quality  CONOPS 
and  chose  to  adapt  the  Edison  and  Frittman  CONOPS  approach  early  in  the  acquisition 
life  cycle  and  updated  it  throughout  the  acquisition  life  cycle  as  the  system  design, 
anticipated  mission  profile  and  system  functionality  evolved. 

The  team  used  methods  and  skills  learned  in  the  MSSE  program  to  develop  a 
Lego  Mindstorms-based  Radiological  Clearance  System,  which  contains  an  unmanned 
ground  vehicle.  The  RCS  high-level  CONOPS  was  initially  developed  to  feed  the 
simulated  JCIDS/DAS  process  and  provide  initial  input  into  the  capabilities  based 
assessment  (CBA).  The  CONOPS  was  used  to  describe  the  organization,  mission, 
objectives,  development,  integration,  and  testing  of  the  system.  As  the  system  evolved, 
the  high-level  CONOPS  matured  into  a  system-level  CONOPS.  During  all  phases  of  the 
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simulated  JCIDS  process,  the  CONOPS  was  used  to  communicate  user  needs  and  system 
requirements  to  system  developers,  system  integrators  and  system  testers  to  ensure  that 
the  RCS  met  the  stakeholder  needs  and  requirements. 

The  initial  high-level  CONOPS  as  presented  in  this  capstone  project  addresses  the 
JCIDS  process  from  a  high-level  military  needs  perspective.  It  represents  the  overall 
capabilities,  as  requested  by  the  user,  to  be  delivered  by  the  system.  The  CONOPS  was 
used  to  communicate  user  needs,  and  to  map  these  needs  to  system  requirements  and 
system  functions.  The  CB  A  was  conducted  to  mature  the  high-level  CONOPS  into  a 
system  specific  CONOPS. 

During  the  JCIDS  process,  requirements  are  initially  captured  in  the  fonn  of  an 
ICD;  however,  as  the  CONOPS  evolves  throughout  the  acquisition  life-cycle  process  the 
requirements  documents  will  change. 

The  system  level  CONOPS  as  captured  in  the  ICD  provides  a  specific  description 
of  system  requirements,  as  it  existed  prior  to  the  material  solution  analysis  (MSA)  phase. 
The  system  CONOPS  continued  its  evolution  and  development  as  the  acquisition 
proceeded  through  the  MSA  phase  and  the  technology  maturity  and  risk  reduction 
(TMRR)  phase.  A  full  system  would  proceed  through  the  engineering  manufacturing  and 
development  (EMD)  phase,  and  the  production  and  deployment  (P&D)  phases,  but  they 
are  outside  the  scope  of  this  project. 

1.  Primitive  High-Level  CONOPS 

A  primitive  high-level  CONOPS  was  developed  to  express  the  full  capability 
described  in  the  user’s  primitive  need  statement.  The  system  was  treated  as  a  “black  box” 
capable  of  providing  the  desired  capability  with  few  limitations.  This  primitive  CONOPS 
was  used  to  guide  the  development  of  the  ICD. 

The  RCS  is  a  radiological  clearance  system  developed  to  locate,  identify,  and 
remove  simulated  radiological  hazards  from  an  operational  area.  In  the  interest  of  further 
developing  the  base  of  knowledge  in  this  area,  Lego  Mindstorms  prototypes  were  used  to 
simulate  the  location,  identification,  and  removal  of  radiological  objects.  To  permit  the 
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widest  distribution  possible  for  the  report  and  associated  documentation,  the  TECHMAN 
team  used  inert  vials  to  stand  in  for  hazardous  objects.  The  capstone  project  also 
replicated  the  initial  analysis,  selection,  design,  development,  deployment,  and  support  of 
the  devices  in  the  SE  life -cycle  sustainment  process. 

Lego  Mindstorms  is  a  Lego  kit  consisting  of  Lego  building  components,  a 
portable  computing  module,  electric  motors,  and  several  different  sensors.  These 
components  can  be  assembled  and  the  computing  module  programmed  to  perfonn 
various  mission  tasks.  During  this  capstone  project,  two  Lego  robots  were  assembled  to 
locate,  identify,  and  remove  inert  plastic  vials  that  were  marked  to  simulate  radiological 
hazards.  The  design  teams  created  an  autonomous  robot  and  a  teleoperated  robot  to 
demonstrate  the  feasibility  of  this  technology.  The  two  robots  were  tested  and  evaluated 
in  a  test  area  to  measure  and  compare  their  ability  to  locate,  identify,  and  remove 
simulated  radiological  containers. 

2.  Initial  Capabilities  Document  CONOPS 

A  capability  analysis  was  conducted  to  identify  existing  materiel  solutions  and 
non-materiel  solutions  available  to  provide  a  portion  of  the  required  capability.  The 
remaining  capability  requirement  was  documented  in  the  ICD  as  a  justification  for  the 
acquisition  of  a  new  materiel  system.  The  CONOPS  was  refined  to  remove  capabilities 
provided  by  existing  materiel  solutions  and  non-materiel  solutions  and  included  in  the 
ICD  to  facilitate  communication  of  the  capability  to  be  provided  by  the  new  system. 

3.  Material  Solution  Analysis  Phase  CONOPS 

During  the  Material  Solution  Analysis  (MSA)  phase,  the  CONOPS  provided  the 

basis  for  analyzing  potential  concepts  for  the  RCS.  The  system  CONOPS  was  used  to 

translate  capability  gaps  into  system-specific  requirements  and  key  performance 

parameters  (KPPs).  The  system-level  CONOPS  was  used  to  develop  an  Analysis  of 

Alternative  (AO A)  and  was  the  foundation  for  evaluation  of  tradeoffs  between  cost, 

schedule,  and  performance  during  this  phase.  The  system  concept  solution,  risk  analysis, 

and  risk  mitigation  plans  were  key  deliverables  that  were  produced  during  the  MSA 
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phase.  The  capabilities  of  existing  systems,  as  well  as  other  DOTMLPF  solutions,  were 
analyzed  to  see  if  a  suitable  effect  could  be  achieved  without  creating  a  new  system  (a 
non-material  solution)(Edson  and  Frittman  2010)  (DODI  2015).  For  more  information  on 
the  AO  A,  see  Chapter  III. 

4.  Technology  Maturation  and  Risk  Reduction  Phase  CONOPS 

The  Technology  Maturity  and  Risk  Reduction  (TMRR)  phase  is  conducted  “to 
reduce  technology,  engineering,  integration,  and  life-cycle  cost  risk  to  the  point  that  a 
decision  to  proceed  to  EMD  could  be  made”  (DODI  2015).  The  TECHMAN  team  made 
design  and  requirement  tradeoffs  necessary  to  ensure  a  functionally  capable  RCS  was 
incorporated  into  the  system  CONOPS. 

In  a  full  system,  the  TMRR  “phase  normally  includes  competitive  sources 
conducting  technology  maturation  and  risk  reduction  events,  preliminary  design  events, 
to  including  preliminary  design  reviews  (PDR)  prior  to  source  selection  for  the  EMD 
phase”  (DODI  2015).  Risk  reduction  prototypes  or  competitive  prototypes  would  be 
included  during  this  phase  if  they  will  reduce  the  EMD  risk  to  an  acceptable  level  (DODI 
2015). 

Risk  reduction  prototypes  or  competitive  prototypes  can  be  at  the  system  level  or 
they  can  focus  on  the  sub-system  or  component  level  of  the  system  prior  to  Milestone  B. 
Competitive  prototyping  or  critical  subsystem  prototyping  of  a  system  is  a  statutory 
requirement  to  be  included  as  part  of  the  Acquisition  Strategy  for  major  defense 
acquisition  programs  (MDAPs).  Technology  Readiness  Assessments  (TRA)  Guidance 
should  be  used  to  benchmark  technology  risk  (DODI  2015) 

The  TECHMAN  sub-teams  each  created  a  prototype  clearance  vehicle  (the 
Autonomous  Clearance  Vehicle  and  the  Teleoperated  Clearance  Vehicle).  At  the  T&E 
event,  the  two  prototypes  were  tested  against  each  other  to  see  which  would  fulfdl  the 
CONOPS  more  effectively.  Technology  limitations  were  identified  during  the  TMRR 
phase.  The  CONOPS  was  updated  to  match  the  more  mature  understanding  of  the 
capability  to  be  delivered. 
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In  an  acquisition  program,  the  acquisition  strategy  will  direct  the  TMRR  phase, 
with  multiple  technology  development  demonstrations  taking  place  before  the  customer 
and  program  manager  (PM)  can  determine  that  a  chosen  solution  is  technologically 
feasible,  affordable,  effective,  suitable,  and  survivable  (DODI  2015).  The  chosen 
technical  solution  must  demonstrate  that  it  satisfies  the  systems  capability  requirements 
and  that  the  technical  risks  are  acceptable.  During  the  TMRR  phase,  the  PM  is  required  to 
plan  and  update  the  acquisition  strategy  for  Milestone  Decision  Authority  (MDA) 
approval.  The  updated  acquisition  strategy  will  describe  the  overarching  approach  to 
fulfilling  the  system  capabilities,  which  will  include  the  programs  schedule,  cost, 
performance  and  business  strategy  (DODI  2015). 

During  the  TMRR  phase  of  a  full  project,  the  PM  will  make  the  initial  critical  life¬ 
cycle  sustainment  decisions  for  the  RCS.  These  decisions  should  be  initiated  early  when 
requirements  tradeoff  and  design  decisions  are  being  made  (DODI  2015).  Finalizing  the 
life-cycle  requirements,  the  PM  will  decompose  them  into  detailed  requirements  to 
support  the  PDR  (DODI  2015).  The  TECHMAN  team  performed  a  limited  form  of  life- 
cycle  planning  due  to  the  limited  scope  of  the  project. 

5.  Engineering  and  Manufacturing  Development  Phase  CONOPS 

For  an  acquisition  program  at  the  MS  B  decision,  the  MDA  provides  the 
authorization  to  award  contracts  and  enter  the  EMD  phase  of  the  DAS  process.  MS  B  is 
the  point  at  which  investment  resources  are  committed  to  the  program  and  a  request  for 
proposals  (RFP)  is  released  to  the  public  to  submit  offers.  The  system  CONOPS  is  a  key 
portion  of  this  step.  If  the  guidelines  discussed  in  this  capstone  project  are  followed, 
contractors  submitting  proposals  should  have  a  complete  and  accurate  listing  of  the 
desired  system’s  operational  and  functional  requirements.  Therefore,  they  should  be  able 
to  complete  proposals  to  build  systems  which  provide  the  capability  set  to  meet  the 
system  requirements.  At  MS  B,  all  risks  (technology,  engineering,  integration,  life-cycle, 
manufacturing,  development,  and  cost)  should  be  adequately  mitigated  to  support  design 
production.  When  an  acquisition  program  is  developed  in  this  fashion,  the  system 
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CONOPS  becomes  a  key  document  in  accurately  developing  the  program’s  cost, 
schedule,  and  performance  estimates. 

The  goal  of  the  EMD  phase  for  an  acquisition  program  is  to  develop,  build  and 
test  the  system  in  order  to  verify  that  all  operational  requirements  have  been  met  in  order 
to  support  a  production  and  deployment  decision.  During  EMD,  all  hardware  and 
software  designs  are  completed.  System  prototypes  are  built  and  tested  to  verify 
compliance  with  capability  requirements.  The  PM  prepares  for  production  or  deployment 
and  establishes  the  initial  product  baseline.  EMD  will  be  when  Developmental  Testing 
and  Evaluation  (DT&E)  will  occur  to  provide  feedback  to  the  PM  on  the  progress  of  the 
system  design  and  provide  infonnation  on  the  adequacy  of  the  program  to  meet  system 
capability  requirements.  Successful  completion  of  product  prototype  testing  will  normally 
be  the  basis  for  entering  low  rate  initial  production  (LRIP).  Independent  operational 
testing  and  Evaluation  (OT&E)  will  normally  also  occur  during  EMD.  OT&E  is 
performed  by  the  component  service’s  operational  test  agency  and  is  designed  to  validate 
that  the  system  achieves  its  intended  operational  mission  (DODI  2015). 

During  EMD,  “the  PM  finalizes  design  of  product  support  elements  and  integrates 
them  into  a  comprehensive  product  support  package”  (DODI  2015).  Product  support  and 
performance  testing  will  be  verified  through  reliability,  availability,  and  maintainability 
(RAM)  testing  to  make  sure  support  packages  and  system  design  meets  system  life-cycle 
requirements. 

Milestone  C  (MS  C)  is  the  point  at  which  the  program  is  reviewed  for  entrance 
into  the  P&D  phase  of  the  JCIDS/DAS  process.  The  general  criteria  for  entry  into  P&D  is 
that  the  system  demonstrate  that  the  production  design  is  stable  and  that  it  will  meet 
system  requirements  based  on  successful  completion  of  DT  and  OT  events  (DODI  2015). 
The  MDA  will  document  the  MS  C  decision  in  an  ADM  at  which  time  the  system  will 
proceed  into  the  P&D  phase. 

Due  to  the  limited  scope  of  the  project,  the  TECHMAN  team  used  an  abbreviated 
EMD  phase  that  consisted  of  completing  the  prototypes  and  perfonning  developmental 
testing.  Due  to  the  limitations  of  the  Lego  Mindstonns  system,  the  TECHMAN  is  not 


24 


suitable  for  actual  operational  environments,  and  due  to  time  and  financial  constraints, 
the  TECHMAN  team  did  not  perform  operational  testing  on  the  prototypes. 

6.  Production  and  Deployment  Phase  CONOPS 

The  P&D  phase  is  to  produce  and  deliver  requirement-compliant  products  for  use 
by  the  component  service  (DODI  2015).  During  the  P&D  phase  “the  product  is  produced 
and  fielded  for  use  by  operational  units”  (DODI  2015).  During  this  phase,  LRIP  and  full- 
rate  production  decisions  are  made  to  support  operational  fielding  of  the  system.  System 
sustainment  and  support  activities  are  implemented  and  carried  out  for  the  life  of  the 
program.  During  this  phase,  system  errors  and  deficiencies  should  be  identified  and 
corrected  prior  to  proceeding  to  full  rate -production.  These  errors  and  deficiencies  along 
with  their  mitigation  strategies  should  be  captured  in  the  system  CONOPS  to  ensure 
implementation  and  correction  in  future  products  (DODI  2015)  (Edson  and  Frittman 
2010). 

The  TECHMAN  team  omitted  the  P&D  phase  due  to  the  limitations  of  the  Lego 
Mindstorms  system  and  due  to  time  and  financial  constraints. 

7.  System- Specific  CONOPS 

The  system  requirements  were  developed  based  upon  the  high-level  CONOPS. 
The  system  CONOPS  was  used  to  translate  capability  gaps  into  system-specific 
requirements  and  KPPs.  These  requirements  formed  the  basis  for  an  analysis  of 
alternatives  and  selection  of  the  best  system  design  as  MS  A.  With  the  system  design 
selected,  the  high-level  CONOPS  evolved  into  a  system-specific  CONOPS.  The 
CONOPS  continued  to  evolve  as  the  system  proceeded  through  the  TMRR  and  EMD 
phases.  It  was  treated  as  a  living  document  and  updated  throughout  the  acquisition  life- 
cycle  to  communicate  user  needs  and  system  requirements  to  system  developers,  system 
integrators,  system  testers,  and  program  budget  analysts  to  ensure  that  the  RCS  met  the 
stakeholder  needs  and  requirements. 
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Technology  limitations  were  identified  during  the  TMRR  phase.  The  CONOPS 
was  updated  to  match  the  more  mature  understanding  of  the  capability  to  be  delivered 
and  facilitate  trade  discussions  that  resulted  in  trades  necessary  to  ensure  an  affordable 
system. 

Further  refinement  of  the  CONOPS  occurred  during  the  EMD  phase  as  hardware 
and  software  designs  were  completed  and  prototypes  were  built  and  tested  to  verify 
compliance  with  capability  requirements.  Sustainment  strategies  and  training  materials 
were  developed,  and  operational  testers  and  evaluators  developed  test  scenarios  based  on 
the  CONOPS. 


8.  Operational  Concept 

When  performing  ground  mobile  or  foot  patrol  operations,  ground  forces  of  the 
U.S.  Army  and  Marine  Corps  face  many  hazards  during  field  combat  operations.  Some  of 
the  hazards  faced  by  these  forces  manifest  themselves  as  IEDs  or  CBRNE  objects  placed 
by  enemy  forces  in  the  operational  area.  Radiological  objects  could  take  the  form  of  a 
nuclear  device,  or  radiological  waste  (a  so-called  “dirty  bomb”)  placed  in  the  area  of 
operation.  When  these  hazards  are  encountered,  American  forces  need  a  method  to 
locate,  identity,  and  dispose  of  the  hazard. 

This  capstone  project  developed  an  RCS  to  locate,  identity,  and  remove  simulated 
hazards  that  represent  what  may  be  encountered  by  U.S.  ground  forces.  The  RCS  must 
have  a  means  for  ground  forces  to  locate  potential  radiological  hazards  in  the  operational 
area.  A  combination  of  radiological  sensors  would  be  used  to  identify  the  hazard  once  it 
is  located.  After  the  radiological  hazard  has  been  identified,  it  must  be  properly 
neutralized  and  disposed  of.  Due  to  the  limitations  of  the  exercise,  inert  “hazards”  and 
sensors  that  can  detect  them  were  used  in  place  of  hazardous  targets. 

9.  Capability  Gaps 

United  States  forces  have  a  need  for  a  system  with  a  long  standoff  distance  to 
locate,  identity,  and  neutralize  hazards  to  ground  combat  troops  and  support  personnel. 
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While  there  are  many  handheld  systems  to  locate  and  identity  known  hazards,  these 
systems  place  the  operator  and  personnel  at  risk  while  perfonning  the  hazard  location  and 
identification  tasks.  A  system  that  operates  at  a  distance  could  accomplish  the  same 
mission  tasks  while  limiting  the  forces  exposure  to  known  or  potential  hazards.  The  use 
of  autonomous  systems  to  accomplish  the  hazard  identification  task  will  limit  battlefield 
casualties  and  keep  a  greater  number  of  forces  in  the  fight. 

B.  CAPABILITY  NEEDS  STATEMENT 

The  Department  of  Defense  needs  a  teleoperated  or  autonomous  system  that  will 
locate,  identity,  and  neutralize  radiological  hazards  without  endangering  the  system 
operators  or  other  personnel.  The  system  must  be  capable  of  traversing  irregular  terrain 
while  locating,  neutralizing,  and  removing  radiological  hazards.  The  system  must  be 
readily  transportable,  reusable,  and  capable  of  neutralizing  multiple  radiological  hazards. 
The  system  must  render  radiological  hazards  hannless  and  safe  for  the  operators  and 
military  personnel  to  operate  or  pass  through  the  area  after  it  has  cleared  the  area. 

1.  Design  Reference  Mission 

The  DRM  test  area,  shown  in  Figure  7,  was  randomly  populated  with  vials  that 
simulate  radiological  hazards.  For  testing  and  evaluation  purposes,  both  robots  ran 
through  identical  randomized  courses  so  that  comparisons  could  be  made  between  the 
two  systems. 
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Figure  7.  DRM  Test  Area  for  RCS 


At  the  beginning  of  the  evaluation,  the  operator  activated  the  robot  and  placed  it 
in  the  start  position.  The  time  to  recover  each  vial  was  recorded.  The  original  plan  was  to 
have  the  UGV  identify  if  the  vial  was  hazardous  or  not.  This  was  to  be  simulated  by  two 
contrasting  colors  of  vials  and  the  color  sensor  on  the  UGV.  However,  it  became  evident 
that  the  color  sensor  could  not  distinguish  the  color  difference  due  to  sensor  position  and 
interference  with  the  claw  used  to  secure  the  vial.  This  effort  was  re-scoped  with  the  new 
mission  to  recover  all  vials  and  place  them  in  the  designated  disposal  area.  After  clearing 
and  stowing  a  vial,  the  UGV  returned  to  the  test  area  to  clear  the  remaining  vials.  The  test 
was  complete  and  the  timer  was  stopped  after  all  of  the  vials  were  removed  from  the  test 
area. 
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2. 


Functional  Description 


Figure  8  shows  the  system  functional  description  (SV-4)  for  the  RCS.  The 
overarching  mission  function  performed  by  the  system  was  the  clearance  of  simulated 
radiological  vials.  The  SV-4  shows  the  decomposition  of  this  overarching  mission 
function  into  sub-functions. 


Figure  8.  System  Functionality  Description  (SV-4)  for  the  RCS 


3.  Operational  Environment 

Table  1  provides  a  summary  of  the  operational  environment  in  which  the  RCS  is 
expected  to  conduct  radiological  clearance  operations.  The  operational  environment  will 
be  secure  with  high  visibility  and  in  the  absence  of  high  wind  or  heavy  rain.  The  RCS  is 
not  expected  to  operate  on  low-friction  surfaces  such  as  mud,  ice,  or  snow-pack. 
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Table  1.  RCS  Operational  Environment 


Characteristic 

Description 

Surface  Conditions 

Concrete,  blacktop,  gravel,  or  forest  floor.  Less  than 

30%  grade.  Not  expected  to  operate  in  mud,  standing 
water  greater  than  25  millimeters  deep,  ice,  or  snow- 
pack. 

Temperature 

Negative  40  degrees  Celsius  to  positive  60  degrees 
Celsius. 

Precipitation 

Less  than  1  inch  per  hour  of  rain,  wind  blown  under 
wind  conditions  shown.  Not  expected  to  operate  in 
snow  or  sleet. 

Wind 

Less  than  30  mile-per-hour  sustained  wind  speed  with 
gusts  not  greater  than  50  miles-per-hour. 

Visibility 

Between  2000  and  200  lumens  measured  at  the  surface. 
Fog  conditions  with  greater  than  5-mile  of  visibility. 

Security 

Operationally  secure  location.  Not  expected  to  survive 
ordnance,  small-arms  fire,  blunt  force  attack,  or  any 
other  form  of  hostility.  Operator  is  not  expected  to 
operate  the  system  within  a  hostile  environment. 

4.  Mission  Success  Requirements 

Initially,  to  achieve  mission  success,  the  RCS  was  to  secure  95%  of  radiological 
targets  (with  80%  confidence),  demonstrate  a  75%  probability  of  achieving  this  mission 
within  two  hours  where  the  area-of-operation  is  400  square-feet  and  contains  area-of- 
operation  containing  10  radiological  samples  and  10  non-radiological  samples.  The  RCS 
shall  also  require  not  more  than  one  operator  and  one  set  of  spare  batteries  with  charger 
and  accomplish  mission  success  within  full  range  of  expected  operational  environments. 
However,  during  testing,  the  mission  area  was  reduced  to  16  square-feet  and  five 
radiological  samples  due  to  the  inability  of  the  ACV  to  operate  in  a  fully  autonomous 
mode  and  the  color  sensors  inability  to  clearly  distinguish  vial  colors. 

5.  Use  Cases 

The  DRM  included  two  specific  use  cases.  These  use  cases  were  designed  to 
demonstrate  the  full  range  of  system  requirements.  Environmental  conditions,  such  as 
wind,  rain,  fog,  and  extreme  temperatures,  were  beyond  the  scope  of  this  capstone  project 
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and  not  included  in  the  use  cases.  Table  2  lists  the  objective,  description,  and  data 
collected  for  the  target  arrangement  for  each  use  case. 


Table  2.  DRM  Use  Cases  for  the  RCS 


Use  Case 


Arrangement  of  Targets 


Standard  Nominal  Clearing  Test 
UC-1  Autonomous  Search 
UC-2  Teleoperated  Search 

Objective:  To  give  a  baseline  comparison  of 
performance  and  reliability  for  autonomous  and 
teleoperation. 

Description:  5  targets  placed  in  a  specific  pattern 
in  a  4-foot  by  4-foot  area.  RCS  starting  point  is 
within  the  corral.  RCS  starts  the  mission  with  new 
batteries. 

Data  Collected:  Time  to  clear  area,  number  of 
targets  returned,  target  identification  category, 
number  of  batter  changes,  and  system  failures  or 
anomalies. 

Non-Standard  Clearing  Test 
UC-1  Autonomous  Search 
UC-2  Teleoperated  Search 

Objective:  To  give  a  Non-Standard  mission 
representative  test  and  ensure  no  bias  between 
autonomous  and  teleoperation. 

Description:  5  targets  placed  in  a  random  pattern 
in  a  4-foot  by  4-foot  area.  RCS  starting  point  is 
within  the  corral.  RCS  starts  the  mission  with  new 
batteries. 

Data  Collected:  Time  to  clear  area,  number  of 
targets  returned,  target  identification  category, 
number  of  battery  changes,  and  system  failures  or 
anomalies. 
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C.  SYSTEM  REQUIREMENTS 

1.  Overall  System  Requirements 

Table  3  provides  a  summary  of  the  overall  system  requirements  for  the  RCS. 
TECHMAN  is  to  be  a  single  operator  system.  This  single,  trained  operator  must  be  able 
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to  transport,  set-up,  and  operate  the  system  within  the  full  range  of  expected  operational 
environments.  The  TECHMAN  system  must  conduct  the  DRM  and  achieve  the  mission 
success  requirements  on  a  single  set  of  new  batteries  and  while  using  teleoperation, 
autonomous  operation,  or  some  combination  of  the  two. 


Table  3.  Overall  System  Requirements  for  the  RCS 


Attribute 

Requirement 

Weight 

Two  containers,  less  than  35  pounds-per-container. 

Batteries 

6  size  AA  batteries,  rechargeable  or  non- 
rechargeable. 

Battery  Replacement 

Less  than  2  minutes  for  trained  operator. 

Battery  Life 

Greater  than  2  hours  of  mission  time. 

Operator 

Not  more  than  one  operator  to  transport,  set-up, 
and  operate. 

2.  Teleoperated  Requirements 

Teleoperation  may  improve  operational  efficiency  when  the  operator  has  specific 
knowledge  regarding  the  location  of  radiological  hazards.  The  RCS  shall  provide  the 
ability  for  teleoperation  when  there  is  unobstructed  line-of-sight  at  a  range  of  30  meters 
and  under,  which  is  the  full  range  of  expected  operational  environments. 

3.  Autonomous  Requirements 

Autonomous  operation  is  required  when  unobstructed  line-of-sight  is  not 
available  for  teleoperation  or  the  operation  must  maintain  greater  than  a  30  meters  of 
standoff.  Autonomous  operation  may  be  combined  with  teleoperation  to  ensure  full 
coverage  of  the  area  of  operation.  The  RCS  must  be  capable  of  logging  the  search  area 
covered  during  teleoperation  and  avoiding  redundant  search  coverage. 

4.  Capability  Development  Document 

Table  4  contains  the  system  requirements  that  would  be  included  in  the  CDD 
within  JCIDS/DAS.  The  requirements  are  divided  into  four  high  level  operational  tasks. 
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The  operational  tasks,  which  are  similar  to  critical  operational  issues  and  criteria  (COIC), 
are  the  “bottom  line  standards  of  performance  that,  if  satisfied,  signify  the  system  is 
operationally  ready  to  proceed  beyond  the  milestone  decision”  (Department  of  the  Army 
2011).  The  requirements  related  to  the  operational  tasks  are  KPPs,  key  system  attributes 
(KSAs),  and  additional  performance  attributes  (APAs). 

KPPs  are  “performance  attributes  of  a  system  considered  critical  or  essential  to 
the  development  of  an  effective  military  capability.  Failure  of  a  system  to  meet  a 
validated  KPP  threshold  value  triggers  a  review  by  the  validation  authority  and 
evaluation  of  operational  risk  and/or  military  utility  of  the  associated  system(s)  if  KPP 
threshold  values  are  not  met.  The  review  may  result  in  validation  of  an  updated  KPP 
threshold  value,  modification  of  production  increments,  or  recommendation  for  program 
cancellation”  (JCIDS  Manual  D-A-l). 

KSAs  are  “performance  attributes  of  a  system  considered  important  to  achieving  a 
balanced  solution/approach  to  a  system,  but  not  critical  enough  to  be  designated  a  KPP” 
(JCIDS  Manual  D-A-l). 

APAs  are  “Performance  attributes  of  a  system  not  important  enough  to  be 
considered  KPPs  or  KSAs,  but  still  appropriate  to  include  in  the  CDD  or  CPD  are 
designated  as  APAs”  (JCIDS  Manual  D-A-l). 

The  requirements  are  expressed  using  Thresholds  (T)  and  Objectives  (O). 
“Performance  below  the  threshold  value  is  not  operationally  effective  or  suitable  or  may 
not  provide  an  improvement  over  current  capabilities”  (JCIDS  Manual  D-A-l).  “The 
objective  value  is  the  desired  operational  goal  achievable  but  at  higher  risk  in  life  cycle 
cost,  schedule,  and  technology”  (JCIDS  Manual  D-A-2). 

The  DOD  JCIDS  Manual  requires  all  systems  to  have  six  mandatory  KPPs  which 
are;  Force  Protection,  System  Survivability,  Sustainment,  Net  Ready,  Energy,  and 
Training.  For  the  purposes  of  this  project  only  the  Energy  KPP  was  considered.  The  other 
mandatory  KPPs  would  be  waived  for  this  type  of  system  for  being  outside  the  scope  of 
this  project.  Waiving  mandatory  KPPs  requires  approval  from  the  appropriate  certifying 
or  endorsing  organization  (JCIDS  Manual  D-A-4) 
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Table  4.  Capability  Development  Document 


Operational 

Task 

Requirement 

Number 

Requiremen 

t 

Operational  Task 

1 :  The  Robot  shall 
pass  and  receive 
mission 
information 

KSA  1 

The  robot  shall  notify  the 
operator  of  system 
malfunctions. 

T=0 

KSA  2 

The  robot  shall  store  a  mission 
log  fde  for  retrieval  by  the 
operator. 

T=0 

KSA  3 

When  returning  a  vial  to  the 
corral,  the  robot  shall  play  a 
distinct  sound  for  a  “hazardous 
vial”  and  a  different  sound  for 
an  inert  vial. 

T=0 

Operational  Task 

2:  The  Robot  shall 
operate  in  its 
intended 
environment 

KPP  1  -  Energy 

Starting  with  fully  charged 
batteries,  the  robot  shall  run  for 
the  specified  amount  of  time 
without  swapping  batteries. 

T:  2  hours,  0:  3 
hours 

KPP  2  -  Transport 

The  system  shall  be 
transportable  in  the  specified 
number  of  containers;  each 
container  shall  be  transportable 
by  a  single  Solder. 

T:  Two  containers, 
with  the  weight  of 
each  container  not 
to  exceed  35  lbs. 

0:  One  container, 
with  a  weight  not 
to  exceed  35  lbs. 

KSA  4 

6  AA  batteries  or  rechargeable 
equivalent  shall  power  the 
robot. 

T=0 

KSA  5 

The  system  shall  operate  in  a 
manner  safe  to  its  operators. 

T=0 

APA  1 

Batteries  shall  be  replaceable 
within  two  minutes. 

T=0 

APA  2 

The  system  shall  comply  with 
the  FCC’s  requirements  for  a 
Class  D  device.  Harmful 
interference,  as  defined  in  the 
FCC  rules,  shall  not  prevent  the 
system  from  accomplishing  the 
mission. 

T=0 

APA  3 

The  system  shall  be  operated  by 
not  more  than  one 
servicemember 

T=0 

Operational  Task 

3 :  The  Robot  shall 
propel  itself  under 
its  own  power, 
including  while 
carrying  vials 

KSA  6 

The  robot  shall  traverse  terrain 
of  smooth  concrete  or  blacktop 
surfaces 

T:  Concrete  or 
blacktop  with 
coefficient  of 
friction  between 

0.2 -0.9 

0:  Gravel  or  forest 
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Operational 

Task 

Requirement 

Number 

Requiremen 

t 

floor 

KSA  7 

The  robot  shall  be  able  to 
change  its  heading  to  any  360 
degree  orientation 

T=0 

KPP  3  -  Clearing 
Area 

The  robot  shall  clear  a 
rectangular  area  (the  “target 
area”)  of  a  defined  size. 

T:  16  square  feet 

O:  625  square  feet 

KPP  4  -  Vial 
Transport 

The  robot  shall  secure  all  vials 
and  return  them  to  the  corral  for 
disposal  by  trained  personnel 
and  a  separate  system  at  the 
required  rate. 

T:  P  (return 
standard  size  vial) 

=  95% 

O:  P  (return 
standard  size  vial) 

=  99% 

KSA  8 

The  robot  shall  distinguish  a 
“hazardous”  colored  vial  from 
vials  of  other  colors  with  a 
specific  probability  of 
distinction. 

T:  P  (distinction): 
90% 

O:  P  (distinction): 
95% 

Operational  Task 

4:  The  Robot  shall 
clear  a  given  area 

KSA  9 

The  system  shall  detect  vials 
under  fluorescent  lighting 
conditions  (between  2000  and 

900  lumens). 

T=0 

of  radiological 
threats 

KSA  10 

A  continuous  blue  marking  not 
less  than  1  inch  thick  shall 
surround  the  target  area. 

T=0 

KSA  11 

The  start  and  end  point  for  the 
robot  shall  be  a  1  ’  by  4’  red 
colored  tile  called  the  corral. 

The  corral  shall  be  located  at  a 
comer  of  the  target  area. 

T=0 

KSA  12 

The  system  shall  have  the 
specified  probability  of 
completing  a  2  mission  hours 
without  an  essential  function 
failure. 

T:  0.75  Probability 
of  completing  a  2 
hour  mission 
without  an 
essential  function 
failure 

O:  0.9  Probability 
of  completing  a  2 
hour  mission 
without  an 
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Operational 

Task 

Requirement 

Number 

Requiremen 

t 

essential  function 
failure 

KSA  13 

The  system  shall  have  the 
specified  probability  of 
completing  2  mission  hours 
without  a  system  abort 

T:  0.95  probability 
of  completing  a  2 
hour  mission 
without  a  system 
abort 

0:  0.99  probability 
of  completing  a  2 
hour  mission 
without  a  system 
abort 

APA  4 

The  system  shall  not  exceed  the 
specified  man  maintenance  hour 
/  operating  hour  (MMH/OH) 
ratio 

T:  0.04  MMH/OH 

O:  0.015 

MMH/OH 

APA  5 

The  system  shall  pass  the 

Standard  Nominal  Test  Pattern 
according  to  the  threshold  and 
objective  values  defined  by  that 
test  pattern. 

T:  See  the  SNTP 

O:  See  the  SNTP 
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III.  ARCHITECTURE  DEVELOPMENT 


A.  DEVELOPMENT  METHODOLOGY 

The  architecture  development  methodology  for  TECHMAN  began  in  the 
requirements  analysis  phase.  The  prime  directive  provided  a  basis  of  establishing  the 
right  requirements  for  the  system.  A  functional  analysis  was  conducted  to  detennine 
necessary  system  functions  while  remaining  within  the  requirement  constraints.  The 
functional  analysis  produced  a  functional  architecture.  Form  should  follow  function  and 
thus,  the  physical  analysis  followed  the  functional  architecture.  The  physical  analysis 
produced  the  physical  architecture.  The  system  architecture  was  modeled  and  validated 
by  Innoslate  (developed  by  SPEC  Innovations).  Furthermore,  two  prototypes  that  were 
designed,  built,  and  tested  provided  insight  into  architecture  development. 

1.  Black  Box  Theory 

The  black  box  theory  was  useful  in  developing  the  functional  and  physical 
architectures.  In  the  black  box  theory,  interacting  objects  are  depicted  as  generic  objects 
that  require  inputs  and  produce  outputs,  but  whose  inner  workings  are  unimportant. 

Inputs  and  outputs  are  classified  as  energy,  matter,  material  wealth,  and  information 
(EMMI).  The  object  performs  a  mechanism  that  converts  input  EMMI  to  output  EMMI. 
Output  EMMI  either  provides  inputs  to  another  object  or  is  dissipated  beyond  the 
boundary  of  the  object  as  a  loss  (heat,  exhaust,  noise,  etc.).  Figure  9  is  an  adaptation  from 
an  SE4151  Systems  Architecting  and  Design  Lecture  on  Objects,  Boundaries,  and 
Interactions  given  by  John  M.  Green.  The  figure  shows  the  flow  of  EMMI  through  an 
object.  The  object’s  internal  control  mechanisms  do  not  need  to  be  fully  understood. 
However,  the  interactions  of  EMMI  between  system  objects  must  be  understood  to 
ensure  proper  integration  of  system  components  in  order  to  achieve  emergent  behaviors 
in  a  system  to  accomplish  the  prime  directive. 
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V. 


Receives 

Input 

(EMMI) 


Output 

(EMMI) 


Losses  EMMI  While 
transforming  Input  EMMI 
into  Output  EMMI 


Figure  9.  Black  Box  Theory  Diagram 


The  TECHMAN  architecture  treats  the  system  objects  within  the  physical 
architecture  as  black  boxes  that  provide  EMMI  inputs/outputs  throughout  the  integrated 
system  structure.  The  use  of  Lego  Mindstorms  components  becomes  an  integration 
exercise.  The  EMMI  inputs  and  outputs  of  these  components  in  the  TECHMAN  system 
and  interactions  between  each  object  are  described  later  in  this  chapter. 

2.  Modularity 

One  advantage  of  using  Lego  Mindstorms  for  TECHMAN  is  modularity.  The 
components  can  be  reconfigured  to  suit  the  needs  of  various  system  objectives.  The  piece 
parts  can  be  disassembled  and  reassembled  to  suit  the  needs  of  follow-on  capstone 
efforts.  Software  code  can  also  be  reused  and  refined  in  follow-on  efforts.  Geographical 
constraints  are  minimized  by  the  ease  of  shipping  physical  components  and  the  electronic 
accessibility  of  source  code. 

B.  FUNCTIONAL  ARCHITECTURE 

The  functional  architecture  outlines  what  the  system  must  do.  For  TECHMAN, 
the  prime  directive  is  to  safely  and  reliably  identify  and  clear  an  area  of  containers 
representing  either  hazardous  or  inert  materials.  The  enabling  functions  for  the  system 
include  but  are  not  limited  to:  transport,  sense,  identify,  secure,  report,  and  signal.  These 
functions  are  organized  in  the  functional  architecture. 
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1. 


Functional  Decomposition 


Table  5  shows  the  allocation  of  functions  from  the  SV-4  from  Figure  8  to  the 
system  requirements,  and  it  also  provides  a  description  of  each  function  and  the 
requirements  associated  with  it. 


Table  5.  Functional  Allocation  to  Requirements 


Function 

Description 

Req. 

1  Conduct 

This  is  the  overall  function  of  the  system.  All  sub 

Operational 

Radiological 

functions  support  this  overarching  function  to  safely  and 

Task  4 

Clearance 

reliably  distinguish  and  clear  an  area  of  radiological  and 
inert  vials. 

1.1  Identify 

This  function  shall  enable  the  system  to  distinguish  a 

KSA  8 

Radiological 

Material 

hazardous  vial  from  a  non-hazardous  vial. 

1.1.1  Perform 

The  system  shall  visually  search  for  vials  using  onboard 

KSA  9 

Visual  Search 

sensors.  This  function  provides  situational  awareness 
and  supports  the  Identify  function. 

1.1.2  Process  Visual 

This  function  enables  the  system  to  distinguish  the 

Search  Data 

difference  between  radiological  and  inert  vials. 

1.2  Traverse  Terrain 

The  system  shall  provide  its  own  source  of  propulsion. 

KSA  6 

KSA  7 

1.3  Remove  Target 

The  system  shale  locate,  secure,  and  carry  the  target  out 
of  a  specified  area  and  places  the  target  into  the  corral 

KPP  4 

1.3.1  Collect  Hazard 

Collecting  the  hazard  involves  sensing  the  hazard, 

KSA  9 

positioning  the  vehicle,  and  securing  the  hazard. 

KPP  4 

APA  5 

1.3.2  Secure  Hazard 

The  system  shall  approach  and  secure  the  vials  for  safe 

KSA  9 

transportation  to  the  corral. 

KPP  4 

APA  5 

1.4  Log  Information 

The  system  shall  maintain  a  log  of  operations  performed 
with  time  data  in  order  to  determine  process 
improvements  in  the  future  or  corrective  actions  for 
issues  that  arise. 

1.5  Communicate 

The  system  shall  communicate  vital  information  to  the 

Operational 

operator.  Sub-functions  will  provide  the  inputs  to  the 
communications  made  to  the  operator. 

Task  1 
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Function 

Description 

Req. 

1.5.1  Send/Receive 

The  system  communicates  status  of  the  vehicle  and  the 

KSA  1 

Data 

secured  target. 

KSA  2 

KSA  3 

1.5.2  Emit  Audible 

The  system  shall  emit  an  audible  alert  indicating  if  the 

KSA  3 

Alert 

target  is  hazardous. 

2.  Functional  Flow  Block  Diagram 

The  functional  architecture  was  shown  previously  as  a  function  hierarchy  diagram 
in  the  SV-4  in  Figure  8.  These  functions  provide  a  basis  for  developing  the  functional 
flow  block  diagram  (FFBD).  The  FFBD  aids  in  model  development  and  simulation  of 
system  behaviors.  Figure  10  shows  the  FFBD  for  a  RCS  nominal  mission. 


Figure  10.  RCS  Functional  Flow  Block  Diagram 
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c. 


PHYSICAL  ARCHITECTURE 


The  physical  architecture  designates  the  system  components  necessary  to 
accomplish  the  actions  in  the  functional  architecture.  While  the  functional  architecture 
outlines  what  to  do,  the  physical  architecture  outlines  how  to  do  it. 


1.  Physical  Architecture  Hierarchy  Diagram 


Figure  1 1  shows  the  physical  architecture  of  the  TECHMAN  system.  It  is 
comprised  of  vehicle  hardware,  logistics  support,  test  and  evaluation,  and  software.  The 
vehicle  hardware  includes  the  EV3  brick,  ultrasonic  sensor,  color  sensor,  touch  sensor, 
motors,  and  other  Lego  structural  components.  The  logistics  support  produces  the 
operation  guide  and  technical  documents.  The  test  and  evaluation  demonstrated  if  the 
TECHMAN  system  accomplished  the  necessary  functions  to  achieve  KPPs  and  the  prime 
directive.  The  software  component  provides  the  necessary  logic  for  the  devices  to 
perform  their  mission  based  on  the  inputs  it  receives  from  onboard  sensors  and  applicable 
inputs  from  the  operator.  Table  6  lists  and  describes  the  active  physical  objects  contained 
in  the  TECHMAN  system. 


Figure  1 1 .  Physical  Architecture 
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Table  6.  Physical  Object  Descriptions 


OBJECT 

DESCRIPTION 

OPERATOR 

I 

II 

The  operator  will  ensure  the  batteries  in  the  EV3  brick  are  fully 
charged  before  mission  begins.  The  operator  will  place  the 
vehicle  in  its  starting  location  and  monitor  the  vehicle  during 
mission  execution.  The  operator  will  remotely  control  the 
teleoperated  variant. 

EV3  BRICK 

The  EV3  Brick  is  the  LEGO  MINDSTORM  control  center.  It 
sends  commands  to  the  motors  and  receives  inputs  from  the 
sensors.  It  can  display  the  system  status  including  battery  level, 
Wi-Fi  and  Bluetooth  connection  status. 

ULTRASONIC  SENSOR 

The  ultrasonic  sensor  is  a  digital  sensor  that  uses  reflected  sound 
waves  to  measure  distance  to  objects  in  its  path.  It  can  detect 
objects  up  to  99  inches  away  with  an  accuracy  of  +/-  0.394 
inches. 

COLOR  SENSOR 

W 

Recognizes  7  different  colors  and  light  intensity.  Sample  rate  of 
1Hz.  Three  modes:  color  mode,  reflected  light  intensity'  mode, 
ambient  light  intensity'  mode. 

LARGE  REGULATED  MOTOR 

fit-'  ' 

Pow'erful  and  precise  robot  action.  The  large  motor  is  a  pow'erful 
“smart”  motor.  It  has  a  built-in  rotation  sensor  with  1-degree 
resolution  for  precise  control.  Runs  at  160-170  rpm  with  20  Ncm 
torque  and  stall  torque  of  40  Ncm. 

MEDIUM  REGULATED  MOTOR 

The  medium  regulated  motor  is  compact  in  size  and  provides  a 
faster  response.  The  medium  motor  includes  a  built-in-rotation 
sensor  but  is  smaller  and  lighter.  Runs  at  240-250  rpm  with  8 

Ncm  torque  and  stall  torque  of  12  Ncm. 

TOUCH  SENSOR 

The  touch  sensor  recognizes  three  conditions:  touched,  bumped, 
and  released.  The  touch  sensor  is  an  analog  sensor. 

FIELD  COMPUTER 

Field  computer  will  receive  communications  from  the  EV3  brick. 

It  will  display  relative  status  information  for  the  operator.  It  also 
contains  the  program  file  that  gets  loaded  to  the  EV3  brick  prior 
to  mission  execution. 

OPERATOR  CONTROL  UNIT 
Tablet  device 

For  the  teleoperated  variant.  The  OCU  sends  drive  commands  to 
the  EV3  brick. 
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The  work  breakdown  structure  (WBS)  identities  the  working  levels  of  effort 
necessary  to  build  the  physical  architecture.  The  WBS  has  been  split  into  five  views  from 
Figure  12  through  Figure  16. 


System 


Level  1 


Level2 


Level3 

Level  4 


Level  5 


1.  Integrate 
Vehicle 
Hardware 


0.  LEGO  ROBOT 
(TECHMAN) 


2.  Provide 
Logistics 
Support 


3.  Conduct  Test 
and  Evaluation 


4.  Develop 
Software 


r 

Top  Level  HH 

MM 

MM) 

Figure  12.  Work  Breakdown  Structure,  View  1  of  5 
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0.  LEGO  ROBOT 
(TECHMAN) 


1 .  Integrate  Vehicle 
Hardware 


2  Provide  Logistics  3.  Conduct  Test  ana 
Support  Evaluation 


1  2  Integrate  Power  1.3  Integrate  Control 
Sub  Systems  Systems 


i.i.i  Desigrvbuikl 
Driving  Mechanism 
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Lifting  Mechanism 

1.1.3  Design/Build 
Transmission 
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Orlving  Mechanism 

1. 1.2.1  Design 
Lifting  mechanism 

1.1. 3.1  Design 
Transmission 

1. 1.4.1  Select 

msion 

1.1. 1.2  Procure 
piece  parts 

1.1. 2.2  Procure 
piece  parts 

1  1.32  Procure 
piece  parts 

1.1. 4.2  procure 
motor  piece  parts 

1  1.1.3  Build  Driving 

1.1. 2.3  Build  Lifting 

1.1. 3.3  Build 

1.1  4.3  Integrate 

mechanism 

Mechanism 

Transmission 

motors  into  de 

sign 

1.1  Integrate 
Chass«i'Drive  Train 
Sub  Systems 


Figure  13.  Work  Breakdown  Structure,  View  2  of  5 


4.  Develop  Software 


0.  LEGO  ROBOT 
(TECHMAN) 


1 .  Integrate  Vehicle 

2.  Provide  Logistics 

3.  Conduct  Test 

4.  Develop 

Hardware 

Support 

and  Evaluation 

Software 

1.1  Integrate 
Chassis/Drive  Train 
Sub  Systems 


1.2  Integrate  Power 
Subsystems 


1.3  Integrate 
Control  Systems 


1.2.1  Design 
Vehicle  Power 
Pack 

1.2.2  Design 
Recharging 
connectors 

1.2.3  Design 
Remote  Control 
power  pack 
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power  pack 
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power  pack 
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Figure  14.  Work  Breakdown  Structure,  View  3  of  5 
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Figure  15.  Work  Breakdown  Structure,  View  4  of  5 
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Figure  16.  Work  Breakdown  Structure,  View  5  of  5 
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D.  ALLOCATED  ARCHITECTURE 


1.  Integration  of  Functional  and  Physical  Architecture 

Figure  17  shows  the  interactions  between  the  active  objects  of  TECHMAN.  The 
large  motors  receive  energy  from  the  EV3  brick.  They  provide  the  propulsion  for  the 
TECHMAN  vehicle.  The  small  motor  receives  energy  from  the  EV3  brick.  It  provides 
the  mechanical  driver  for  opening  and  closing  the  claw  that  secures  the  vials.  Each  of  the 
sensors  (ultrasonic,  color,  and  touch)  receives  energy  from  the  EV3  brick  and  in  turn 
sends  infonnation  back  to  the  EV3  brick  in  the  form  of  a  voltage  output.  The  EV3  brick 
sends  infonnation  to  the  Field  Computer.  The  Field  computer  displays  information  to  the 
user.  The  user  sends  physical  inputs  into  the  field  computer  and  to  the  OCU  on  the 
teleoperated  variant.  The  OCU  sends  information  to  the  EV3  brick. 


Large  Motors 


Field 

Computer 


Small  Motor 


Ultrasonic  Sensor 


EV-3  Brick 


Tele-operated 

Variant 


Color  Sensors 


Touch  Sensor 


Figure  17.  TECHMAN  Component  Diagram 
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2. 


Allocated  Architectural  Diagram 


Table  7  lists  the  inputs,  outputs,  and  function  allocation  for  each  of  the  active 
objects  in  the  system. 


Table  7.  Functional  Allocation  and  I/O  of  Physical  Objects 


OBJECT 

INPUT 

OUTPUT 

FUNCTION 

OPERATOR 

Visual  situational 
awareness,  food,  water 

Inputs  to  the  field 
computer  and  OCU 

1,  1.5 

EV3  BRICK 

Power  supply, 
transmissions  from 

OCU,  voltage  from 
sensors 

Voltage  to  motors  and 
sensors,  transmissions  to 
field  computer,  audio 
alerts 

All  vehicle 
functions 

ULTRASONIC 

SENSOR 

Voltage  from  EV3,  echo 
sound  waves 

Voltage  to  EV3,  pulse 
sound  waves 

1.1.1,  1.3.1,  1.3.2 

COLOR  SENSOR 

Voltage  from  EV3,  light 
wavelengths 

Voltage  to  EV3,  source 
light  beam 

1.1.2 

LARGE 

REGULATED 

MOTOR 

Voltage  from  EV3, 

Torque 

1.2 

MEDIUM 

REGULATED 

MOTOR 

Voltage  from  EV3, 

Torque 

1.3.2 

TOUCH  SENSOR 

Voltage  from  EV3,  force 

Voltage  to  EV3 

1.3.2 

FIELD 

COMPUTER 

User  inputs,  source  code 
updates, 

communications  from 

EV3  brick 

Display  of  information  to 
user 

1.5 

OPERATOR 
CONTROL  UNIT 

Inputs  from  user. 
Depressing  buttons,  etc. 

Information  to  EV3  brick 
transmitted  wirelessly 

1.5 
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IV.  UGV  WITHIN  THE  JCIDS  /  DAS  PROCESS 


A.  ANALYSIS  OF  ALTERNATIVES 

Two  AO  As  were  performed  in  support  of  this  project.  The  first  was  the  program- 
level  AOA  used  to  support  the  MS  A  decision.  The  second  AOA  performed  was  the 
subsystem  level  AOA.  This  AOA  was  used  in  the  software  decision  for  the  TECHMAN 
system. 


1.  Program  Level  AOA 

The  program-level  AOA  was  used  to  directly  support  the  MS  A  decision  and  the 
JCIDS/DAS  process.  It  is  the  AOA  that  would  normally  be  used  to  determine  the  path  of 
the  program.  This  AOA  was  done  simply  as  an  exercise  as  this  project  was  directed  to 
use  the  Lego  Mindstorms  system  from  the  beginning. 

a.  Initial  Candidate  Alternatives 

Three  candidates  were  considered  in  the  program-level  AOA.  The  candidates 

were: 

•  Status  Quo  -  The  status  quo  is  assuming  the  service  member  find  and  clears 
the  vials  by  hand. 

•  Modification  of  a  legacy  system  -  Modification  of  a  legacy  system  would  be 
taking  an  already  fielded  system  and  modifying  it  to  meet  the  new  user  need. 
For  this  AOA  the  currently  fielded  Talon  system  was  considered  as  the  legacy 
system. 

•  New  developmental  system  -  The  new  developmental  system  is  the  option 
that  the  team  develops  a  new  system.  This  option  is  what  the  TECHMAN 
system  falls  under. 
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b.  Evaluation  Measures 

The  team  developed  evaluation  measures  that  were  used  to  detennine  the  best 
option  to  take.  The  evaluation  measures  included: 

•  capability  of  the  system  to  clear  standard  radiological  vials 

•  ability  to  provide  safe  standoff  distance  for  servicemembers  from  vials 

•  capability  of  the  system  to  operate  teleoperated  and  autonomous 

•  transportability  of  the  system  to  the  mission  site 

•  cost  of  the  system 

Decision  Factors 

Table  8  depicts  the  three  options  against  the  evaluation  analysis  and  cost  analysis. 
As  can  been  seen  in  the  table,  the  status  quo  is  eliminated  due  to  not  providing  standoff 
for  service  members.  Modification  of  the  Talon  would  likely  be  effective  in  completing 
the  mission  however  the  system  is  heavy  and  difficult  for  dismounted  troops  to  transport. 
Early  analysis  of  the  TECHMAN  system  and  market  research  showed  the  system  would 
be  capable  of  meeting  the  effectiveness  measures  and  be  light  enough  for  transport  by 
one  service  member.  The  team  conducted  a  market  research  by  viewing  the  capabilities 
of  other  Lego  Mindstorms  systems  people  had  posted  on  the  Internet. 
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Table  8.  AO  A  Decision  Analysis 


Status  Quo 
(Servicemembers 
retrieving  vials  by 
hand) 

Modification  Legacy 
System  (Talon) 

New  Developmental 
System  (TECHMAN) 

Effectiveness 

Analysis 

Will  not  provide  standoff 
for  servicemembers 

Will  meet  all  of  the 

evaluation  measures  but  a 
large  and  heavy  system. 

-Not  transportable  by  one 
servicemember 

Research  shows  the 
system  will  be  capable 
of  meeting  evaluation 

measures 

Cost 

Analysis 

No  additional  system 
cost  but  requires 
additional 

servicemembers,  raising 
overall  cost 

Highest  overall  program 

cost 

Lowest  overall  program 

cost 

Cost  was  considered  for  this  analysis;  however,  it  is  not  a  fair  comparison  due  to 
the  nature  of  a  simulated  system  being  built  from  Lego  Mindstorms  verses  a  real  fielded 
military  system.  The  cost  of  both  the  initial  system  and  support  throughout  the  life-cycle 
of  the  Talon  system  is  orders  of  magnitude  larger  than  the  TECHMAN  system. 

c.  Final  Decision 

The  TECHMAN  was  selected  as  the  system  to  use  due  to  its  ability  to  meet 
requirements,  its  ease  of  transportability,  and  its  lower  cost. 

2.  Subsystem-Level  AOA 

A  subsystem  AOA  was  used  to  select  the  software  environment  used.  The  team 
was  offered  licenses  and  documentation  for  the  ROBOTC  Robotic  Operating  System,  or 
documentation  for  the  community  supported  LeJOS  operating  system.  Each  system 
included  an  Integrated  Development  Environment,  hardware  compilers,  and  support 
libraries.  Since  ROBOTC  is  based  around  the  C  programming  language  and  LeJOS  is 
based  around  the  Java  programming  language,  the  team  could  only  select  one  whole 
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environment  or  the  other.  Using  parts  from  ROBOTC  and  parts  from  LeJOS  is  not 
supported  by  either  system. 

This  additional  AOA  was  not  completed  to  directly  support  JCIDS/DAS 
documentation  but  support  the  design  of  the  system. 

a.  Initial  Candidate  Alternatives 

Two  candidates  were  considered  in  the  subsystem-level  AOA.  The  candidates 

were: 

•  using  leJOS  for  the  Operating  System 

•  using  ROBOTC  for  Operating  System 

b.  Evaluation  Measures 

The  team  developed  evaluation  measures  that  were  used  to  determine  the  best 
option  to  take.  The  evaluation  measures  included: 

•  range  of  alternative  Linux  based  operating  system 

•  familiarity  of  software  for  programmers 

•  programming  methods 

•  collaboration  ability 

•  ability  to  control  TECHMAN 

c.  Decision  Factors 

The  team  analyzed  the  two  approaches  against  evaluation  measures  and  selected 
the  preferable  option  based  on  team  judgment.  For  most  of  the  measures,  one  of  the  two 
options  as  preferable.  For  some  of  the  measures,  however,  neither  option  was  clearly 
preferable.  The  results  of  the  analysis  are  shown  in  Table  9. 
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Table  9.  Subsystem  AOA  Decision  Analysis 


Measures 

ROBOTC 

leJOS 

Preferable  Option 

Language 

Based  on  ANSI  C 

Java  SE  Embedded 

leJOS 

License 

Proprietary  Commercial 
Software 

Open  Source 

No  Preference 

Cost  Analysis 

$49 -$139  Per  Seat 

Free 

leJOS 

Operating 

System 

Windows  Only 

Windows 

Linux 

Mac 

leJOS 

Supported 

Platforms 

Lego  Mindstorms 

VEX  Robotics 
Arduino 

Lego  Mindstorms 

No  Preference 

Runtime 

Environment 

Native  (Hardware 
Specific) 

Java  Virtual  Machine 

No  Preference 

Integrated 

Development 

Environment 

(IDE) 

ROBOTC  Proprietary 

Eclipse  IDE 

leJOS 

Source  Control 

3rd.  Party  External 

Plug-in  Support 

leJOS 

Support 

Official  Paid  (Included 
with  License) 
Community 

Community 

ROBOTC 

Maturity 

Stable  Release 

Beta  Release 

ROBOTC 

d.  Final  Decision 

LeJOS  was  selected  as  the  system  to  use  due  to  developer  familiarity  with  Java 
programming  language,  and  the  ability  to  support  multiple  development  environments 
across  multiple  systems,  including  support  for  our  source  control  platfonn.  The  team  also 
did  not  consider  the  fact  that  LeJOS  is  beta  software  with  community  support  to  be 
insurmountable  problems  for  this  effort.  However,  on  a  full-scale  development  effort,  this 
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may  have  tipped  the  scales  towards  ROBOTC  due  to  its  official  support  and  stable 
releases. 

B.  RISK  ANALYSIS 

Risks  were  identified,  managed,  and  assessed  throughout  the  life  of  the  project. 
Identified  risks  fell  into  two  categories:  project  risks  and  technical  risks.  Project  risks  are 
high-level  risks  that  impact  cost  and  schedule.  Technical  risks  are  those  that  relate 
directly  to  the  TECHMAN  system. 

1.  Risk  Identification  and  Analysis 

All  of  the  project  team  contributed  to  identifying  and  managing  risks.  The  WBS 
was  the  top  level  starting  point  for  identifying  risks.  A  top-level  and  low-level 
identification  approach  was  used  such  as  brainstonning  amongst  the  team  and  technology 
analysis. 

Once  the  risks  were  identified,  they  were  analyzed  and  put  into  a  risk  category  of 
project  or  technical.  For  each  risk  identified  the  root  cause,  likelihood  of  occurrence,  and 
the  consequence  of  that  occurrence  were  determined.  Table  10  is  the  guide  for  the 
likelihood  of  occurrence  and  Table  1 1  is  the  guide  for  the  determining  the  consequence. 
Figure  1 8  will  be  used  to  determine  the  rating  of  each  risk. 


Table  10.  Risk  Likelihood  Levels 


Level 

Likelihood 

Probability 

1 

Not  Likely 

-10% 

2 

Low  Likelihood 

-30% 

3 

Likely 

-50% 

4 

Highly  Likely 

-70% 

5 

Near  Certainty 

-90% 
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Table  11.  Risk  Consequence  Levels 


Level 

Cost  Impact 

Schedule  Impact 

Technical  Impact 

1 

Minimal  or  None 

Minimal  or  None 

None 

2 

Increase  <  3%  of  Budget 

Slip  <  1  Month 

1  Requirement  Not  Met 

3 

Increase  <  6%  of  Budget 

Slip  <  2  Months 

2  Requirements  Not  Met 

4 

Increase  <  9%  of  Budget 

Slip  <  3  Months 

3  Requirements  Not  Met 

5 

Increase  >  9%  of  Budget 

Slip  >  3  Months 

4  Requirements  Not  Met 

Consequence 

Figure  18.  Risk  Matrix 


After  the  risks  were  identified  and  scored,  a  decision  was  made  of  how  to  avoid, 
reduce,  eliminate  or  control  the  risk.  The  identified  risk  was  tracked  using  a  database  and 
managed  using  good  engineering  judgment.  Team  TECHMAN  monitored  and  discussed 
the  risks  as  the  need  arose.  The  risk  scores  were  updated  as  their  status  changed. 

2.  Identified  Project  Risks 

Table  12  shows  the  project  risks  as  initially  identified,  along  with  their  associated 
score,  root  cause,  likelihood  of  occurring,  consequence  of  occurring,  and  the  mitigation 
taken. 
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Table  12.  Project  Risks 


Root  Cause 


Not  gaining  the 
knowledge  to 
answer  the 
questions  while 
completing  the 
project 


Team  not  meeting 
delivery  dates 
(Project  Risk)  Score 
-  15 


Likelihood  Consequences 


Due  to  the  short 
time  period, 
location  of  team 
members  and 
member’s  other 
time  commitments 
may  not  get  tasks 
done 


5  -  Due  to  the 
simulated  nature 
and  short  time 
frame  solid 
answer  may  not 
be  found 


3  -  Members  are 
committed  to  the 
project  and  team 
so  likelihood  of 
large  delay  is  low 


3  -  Not  gaining 
the  insight 
required  and 
having  a  good 
report 


3  -  Not  getting 
the  project 
done  causing 
failure 


Mitigation 


Perform  literature  review 
to  point  the  project  in  the 
right  direction.  Ensure 
the  questions  are  able  to 
be  answered 


Have  a  good  schedule. 
Use  EVM  to  track 
progress.  Hold  everyone 
responsible  for  tasks. 


Due  to  the  nature  of  using  simulated  systems  and  a  simulated  IPT  some  of  the 
research  questions  could  not  be  answered  definitively.  Developing  the  TECHMAN 
systems  provided  good  insight  and  helped  the  team  have  a  high  level  understanding  of  the 
information  needed  to  answer  the  research  questions. 

The  TECHMAN  team  was  able  to  meet  delivery  dates  for  the  project  by  setting 
and  following  an  internal  schedule.  EVM  was  used  to  ensure  the  program  was  on  track. 

3.  Identified  Technical  Risks 

Table  13  shows  the  technical  risks  as  initially  identified  with  their  associated 
score,  root  cause,  likelihood  of  occurring,  consequence  of  occurring,  and  the  mitigation 
taken. 
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Table  13.  Technical  Risks 


Risk 

Root  Cause 

Likelihood 

Consequences 

Mitigation 

Teleoperated  Robot 
not  having  the 
required  range  to 
complete  the  DRM 
(Technical  Risk) 

Score  -  19 

Robots  not  having 
capability  to  meet 
requirements  to  due 
component 

limitations  or  time 

constraints 

4  -  Development 
has  shown  the 
robots  may 
struggle  to  meet 
requirements 

3  -  The  robot  will 
not  perform  the 
mission  as 
required 

Continue 

component  testing 
and  software 

refinement. 

Bluetooth  will  not 
have  required  range. 
Test  location  does 
not  have  Wi-Fi;  Wi¬ 
Fi  will  be  brought  to 
location. 

3  -  due  to  the 

unknown  this 

risks  is  scored 

medium 

4  -  Testing  will 
not  be  able  to  be 
completed 

Go  and  test  Wi-Fi  at 

the  test  location 

before  the  DT 
testing. 

Robots  not  being  able 
to  grab  and  transport 
vials  during  testing 
(Technical  Risk) 

Score  -  14 

Using  Legos  has 
inherent  limitations 

2  -  The  vials  are 
light 

4  -  Robot  will  fail 

mission 

Component  testing 
to  ensure  the  arm  is 
capable  of  carrying 
the  vials 

Autonomous  robot 
being  able  to 
complete  the  mission 
without  operator 
input  (Technical 

Risk)  Score  -  1 8 

Hardware  or 
software  not  having 
the  capability  to 
perform  the  mission 
completely 
autonomously 

4  -  Issues  have 

been  found 

during 

component 

testing  and 

software 

development 

3  -  The  robot  will 
require  more 
input  from  the 
operator 

Continue 

component  testing 
and  software 

refinement. 

Software  not 
functioning  properly 
during  testing 
causing  a  mission 
failure  (Technical 
Risk)  Score  -  13 

Short  timeframe  and 
small  team  writing 
software 

4  -  Software 

anomalies  will 

likelihood  be 

encountered 

2  -  buggy 
software  can  be 

dealt  with  in  a  DT 

environment 

Component  testing 
will  find  most  bugs. 
Small  bugs  that 
required  a  system 
restart  will  not  be  a 
big  deal  in  DT 

Color  sensors  not 
being  able  to  find 
vials  due  to  lack  of 
range  or  capability 
of  distinguishing 
vial  colors 

4  -  Issues  have 

been  found 
during 
component 
testing 

4  -  The  robot  will 

fail  the  mission 

Continue 

component  testing 
and  software 

refinement.  Use 

colors  on  the  vials 

the  sensor  can  find 

The  TECHMAN  systems  completed  testing  and  had  favorable  results.  During  the 
design  process  and  testing  all  except  two  of  the  risks  were  mitigated  or  did  not  come  to 
fruition.  The  two  risks  that  were  realized  were  “robots  not  meeting  requirements”  and 

“autonomous  robot  being  able  to  complete  the  mission  without  operator  input.” 
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Due  to  limitations  of  the  Lego  Mindstorms  hardware,  the  team  needed  to  adjust 
the  scope  of  our  project.  The  search  area  was  lessened  dramatically  (from  20  feet  square 
to  four  feet  square).  Additionally,  due  to  problems  with  path  finding,  the  ACV  could  not 
return  to  a  known  position  to  start  every  run.  As  a  result,  the  team  allowed  the  ACV  to 
seek  and  return  one  vial,  then  be  restarted  by  the  operator. 

If  the  program  proceeded  past  MS  B,  then  the  requirements  could  be  changed  to 
fit  with  the  current  capability  of  the  system.  The  more  likely  case  would  be  sufficient 
system  refinements,  either  with  the  software  or  the  hardware  or  both,  to  ensure  the 
revised  system  would  satisfy  the  original  requirements  of  the  user. 
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V.  SYSTEM  DESIGN 


A.  HARDWARE  DESIGN 

An  early  design  decision  made  by  the  TECHMAN  team  was  that  the  ACV  and 
TCV  should  use  identical  hardware  designs  and  differ  only  in  software.  This  constraint 
was  largely  time-based;  the  team  did  not  feel  there  was  enough  time  to  debug  two 
hardware  designs  along  with  two  software  designs.  The  original  hardware  design  as  seen 
in  Figure  19  was  heavily  influenced  by  Grabby,  the  robot  proposed  by  Bagnall  to 
demonstrate  the  EV3  Control  Center  program  for  debugging  EV3  robots. 


Figure  19.  Early  TECHMAN  Design  Prototype 

The  final  version  of  the  hardware  design  was  an  amalgamation  of  iterating 
experimental  designs,  sub-components  from  reference  designs,  modeling  with  Lego 
Digital  Designer,  and  lessons  learned  from  the  initial  design.  The  Digital  Designer  model 
can  be  seen  in  Figure  20.  The  resultant  hardware  was  designed  in  a  modular  manner, 
allowing  for  rapid  testing,  evaluation,  and  reimplementation  of  sub-components  as 
necessary.  The  final  physical  assembly  can  be  seen  in  Figure  21  and  Figure  22. 
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Figure  20.  Digital  Designer  Model  View 


Figure  21.  Final  Hardware  Assembly  View  1 
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Figure  22.  Final  Flardware  Assembly  View  2 


The  most  notable  design  change  from  the  initial  platform  is  the  positioning  of  the 
EV3  brick  and  the  track  design.  The  original  design  utilized  the  EV3  as  an  integral  part  of 
the  chassis  resulting  in  substantial  disassembly  of  the  platfonn  to  change  the  power 
source.  The  original  design  also  experienced  problems  with  the  tracks  coming  off.  The 
final  design  used  a  triangle  orientation,  which  eliminated  the  issue  of  losing  the  tracks. 
Unlike  the  initial  design,  which  was  primarily  focused  on  the  drivetrain,  planning  the 
final  hardware  design  also  included  further  consideration  of  sensor  positioning.  This  was 
a  crucial  component  of  the  platfonn. 

The  team  also  decided  that  both  devices  should  use  the  same  software 
environment.  As  mentioned  in  the  AO  A,  the  team  selected  leJOS  because  the  higher 
familiarity  the  team  had  in  working  in  Java  than  in  C  and  because  leJOS  supports  full 
IDEs  that  are  compatible  with  other  programming  tools,  notably  our  Microsoft  Team 
Foundation  Server-based  source  control  solution. 

Although  the  team  ran  into  a  few  issues  with  the  leJOS  support  libraries,  leJOS 
was  used  in  the  final  TECHMAN  ACV  and  TOY. 
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B. 


DRIVETRAIN  DESIGN 


The  original  drivetrain  was  a  simple  two-tread  design  with  two  wheels  per  tread 
(one  at  the  fore  and  one  at  the  aft).  The  prototypes  used  the  large  regulated  motors  in  a 
front-wheel  drive  configuration.  Each  tread  was  controlled  by  one  motor;  there  is  no  axle 
that  interconnects  the  left  and  right  sides.  The  robot  steers  via  differential  steering.  It  can 
only  turn  by  rotating  one  tread  forward  and  the  other  in  reverse,  thus  accomplishing  a 
zero  point  turn. 

The  ultimate  decision  to  proceed  with  a  treaded  drivetrain  instead  of  a  wheeled 
design  was  based  on  the  analysis  of  their  respective  strengths  and  weaknesses.  Utilization 
of  a  wheeled  design  would  have  simplified  the  drivetrain,  which  would  have  benefited 
sustainability  and  maintainability.  Although,  the  treaded  design  requires  more 
components  and  increased  complexity,  it  provided  a  significantly  more  stable  operating 
platform.  The  treads  allow  for  increased  points  of  contact  with  the  terrain,  which  enables 
the  system  to  overcome  gradients,  or  obstacles  that  would  destabilize  a  wheeled  design  or 
cause  it  to  get  stuck.  Additionally,  choosing  the  treaded  drivetrain  allowed  us  to  take 
advantage  of  the  leJOS-provided  Differential  Pilot  class.  If  implemented  and  trimmed 
correctly,  the  Differential  Pilot  class  is  capable  of  sending  the  robot  forward  or  backward 
by  precise  distances  and  rotating  at  precise  angles.  Initial  testing  with  the  Differential 
Pilot  class  was  promising  but  overall  performance  was  inconsistent  due  to  trim  issues 
stemming  from  the  original  tread  design. 

Robots  using  the  Differential  Pilot  library  need  to  be  “trimmed”  in  order  for  the 
EV3  to  perform  the  calculations  necessary  for  precise  movement.  This  process  involved 
measuring  the  radius  of  the  wheels  for  forward  and  backward  movement  and  the  width  of 
the  wheelbase  for  rotations.  The  library  assumes  that  the  robot  will  be  using  circular 
wheels  (instead  of  oval  treads)  and  that  the  tires  are  very  narrow.  The  treads  are 
approximately  one  inch  wide,  while  the  smallest  tire  in  the  kit  has  a  width  of  less  than 
1/16  inch.  The  team  eventually  made  modifications  to  the  measurements  so  the  devices 
traveled  nearly  the  correct  distance.  The  adjustment  factor  is  time  consuming  to  find  and 
varies  by  surface  on  which  the  device  is  driving. 
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Also  causing  issues  in  the  original  design  was  a  series  of  design  flaws  affecting 
the  treads.  The  structure  surrounding  the  treads  was  insufficiently  rigid  as  shown  in 
Figure  23.  The  axles  would  flex  in  and  bow  out  while  the  robot  was  driving.  This  made 
calculating  the  precise  measurements  difficult.  This  also  affected  the  robot’s  heading,  so 
it  would  drive  at  an  angle  instead  of  driving  straight.  Additionally,  the  treads  themselves 
were  not  tense  enough,  which  allowed  them  to  slip  while  driving,  resulting  in  incorrect 
distance  measurements.  Due  to  these  flaws,  a  complete  redesign  of  the  drivetrain  was 
necessary  to  improve  the  tread  effectiveness. 


Figure  23.  Initial  Track  Design 


The  rigidity  of  the  supporting  structure  was  first  addressed  by  reconfiguring  the 
structure  in  order  to  reduce  the  distance  between  the  motor  and  the  tread’s  drive  wheel. 
Since  the  axle  acts  as  a  class  2  lever,  reducing  the  distance  between  the  drive  wheel  and 
the  motor  also  reduced  the  degree  of  flex  in  the  axle.  Furthermore,  the  team  added  a  twin 
set  of  gears  to  the  tread’s  supporting  structure.  The  main  purpose  of  the  gears  was  to 
provide  additional  tension  on  the  treads  by  changing  the  shape  of  the  treads  from  an 
ellipse  to  an  obtuse  triangle.  Additionally,  the  brackets,  which  held  the  gears  in  place, 
provided  additional  mounting  points  for  the  supporting  structure,  which  helped  increase 
rigidity.  These  two  changes  to  the  drivetrain  yielded  significant  improvements,  which 
minimized  issues,  experienced  with  the  original  design.  Figure  24  shows  the  redesigned 
track. 
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Figure  24.  Redesigned  Track 


C.  CLAW  DESIGN 

The  original  claw  design,  shown  in  Figure  25,  was  simple  and  used  the  medium 
regulated  motor  to  turn  a  worm  screw  that  turned  a  gear  connected  to  an  axle.  At  either 
end  of  the  axle  knob  wheels  were  mounted,  which  turned  matching  knob  wheels  mounted 
inside  the  claws.  Rotating  the  wonn  screw  clockwise  lowered  the  claws  until  they  were  in 
their  lowest  position.  Clockwise  rotation  of  the  wonn  screw  after  the  claw  is  in  the  lowest 
position  opens  the  claws.  Running  the  screw  in  reverse  closed  and  raised  the  claws.  Each 
claw  had  three  “fingers,”  with  a  rubber  disk  mounted  between  the  top  and  middle  finger 
to  make  it  easier  to  grip  things. 


The  original  design  had  a  few  issues.  First,  the  disks  helped  grip  medium  sized 
vials,  but  some  small  vials  still  could  not  be  gripped  within  the  claw.  Additionally,  by 
running  the  motor  too  far  in  either  direction,  the  knob  wheels  could  become  misaligned 
(and  potentially  could  break  if  this  was  done  too  often). 

Improving  the  claw  required  a  complete  redesign  of  both  the  claw  itself  as  well  as 
the  gearbox,  which  transferred  power  from  the  motor.  The  primary  objectives  for 
redesigning  the  claw  was  to  increase  the  rigidity  of  the  claw  structure,  improve  reliability 
when  attempting  to  collect  different  sized  objects,  and  finally  avoid  the  potential  of 
binding  or  stripping  the  gearbox. 

The  first  stage  of  the  redesign  involved  changing  the  gearbox.  Instead  of  using  a 
worm  gear,  which  is  prone  to  binding  when  over-torqued,  a  single  bevel  gear  powered  by 
the  motor  and  connected  to  a  three-stage  series  of  spur  gears  was  implemented.  Although 
this  configuration  was  more  complex,  the  potential  of  binding  gears  is  significantly 
reduced  by  spreading  the  amount  of  torque  over  multiple  gears,  which  can  be  firmly 
mounted  to  the  chassis.  The  redesigned  gearbox  resulted  in  a  smaller  horizontal  footprint 
within  the  chassis,  allowing  for  optimal  placement  of  the  color  sensor  immediately 
behind  the  claw. 

When  redesigning  the  claw,  improving  its  rigidity  was  addressed  first.  Several 
iterations  were  necessary  to  achieve  the  correct  balance  of  strength  while  maintaining  full 
range  of  motion  without  obstructing  the  forward-mounted  color  sensor.  The  gripping 
mechanism  was  reinforced  through  the  additional  supports  at  the  base  and  tip  of  the 
“fingers.”  The  reliability  of  the  gripping  mechanism  was  improved  by  adding  an 
additional  row  of  fingers  to  the  bottom  of  the  claw  as  well  an  additional  set  of  disks  to  the 
tip  of  the  fingers.  The  disks  served  two  purposes  in  improving  the  claw’s  reliability.  First, 
while  the  claw  closes  around  the  intended  target,  the  disks  help  guide  the  object  into  the 
center  of  the  claw.  Second,  the  rubber  on  the  rollers  provides  additional  friction  once  the 
claws  have  closed,  preventing  the  captured  object  from  slipping  out.  The  final  claw 
design  can  be  seen  in  Figure  26. 
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Figure  26.  Final  Claw  Design 


D.  SENSOR  INTEGRATION 

Since  the  hazardous  vials  were  to  be  a  different  color  than  the  non-hazardous 
vials,  the  team  planned  on  using  the  forward  color  sensor,  shown  in  Figure  27,  to  identify 
them.  Additionally,  the  team  needed  some  way  for  the  robot  to  identify  the  boundaries  of 
the  area.  The  team  decided  to  mark  the  area  on  the  ground  with  tape  and  use  a  second 
color  sensor  to  identify  the  tape  as  shown  in  Figure  28.  The  tape  was  for  convenience 
with  the  TCV,  but  necessary  to  the  ACY  to  assist  in  its  autonomous  dead  reckoning. 


Figure  27.  Forward  Color  Sensor 
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Figure  28.  Drag  Color  Sensor 


The  touch  sensor  was  used  as  a  safety  switch  to  prevent  the  claw  from  being 
raised  too  far  (see  Figure  29).  It  serves  as  a  mechanical  failsafe  that  protected  the  claw 
from  retracting  too  far.  The  drag  color  sensor  also  had  failsafe  functionality.  It  could  be 
queried  to  see  if  there  was  a  reflected  light  source  within  its  five-centimeter  range.  If 
there  was  not,  it  meant  that  the  sensor  is  more  than  five  centimeters  from  the  ground, 
presumably  because  its  operator  has  lifted  the  robot  into  the  air.  The  ACV  will  stop  all 
motors  if  the  operator  lifts  up  the  robot. 


Figure  29.  Touch  Sensor 


The  TECHMAN  robots  used  the  ultrasonic  sensor,  shown  in  Figure  30,  as  a 
rangefinder.  The  ultrasonic  sensor  has  a  theoretical  maximum  range  of  255  centimeters; 
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however,  Bagnall  suggest  a  maximum  range  of  180  centimeters,  with  objects  beyond  that 
not  reliably  located.  The  TECHMAN  team’s  testing  found  that  range  to  be  optimistic  as 
well,  and  detennined  that  a  maximum  reliable  range  is  120  centimeters.  The  infrared 
sensor  was  also  an  option  for  range  finding.  It  did  not  perfonn  as  well  as  the  UT  sensor  as 
a  range  finder  and  was  not  used  in  the  final  design. 


Figure  30.  Ultrasonic  Sensor 


E.  SUPPORT  KIT 

In  addition  to  the  robotic  device  (either  the  ACV  or  the  TCV),  the  TECHMAN 
system  includes  several  other  pieces  of  equipment.  The  end  user  is  also  part  of  the 
system,  however,  creating  TECHMAN  end  user  training  is  outside  the  scope  of  our 
exercise. 

The  intent  was  to  border  the  target  area  on  all  four  sizes  with  blue  painter’s  tape. 
The  team  selected  painter’s  tape  because  it  is  readily  available  in  a  variety  of  fairly 
standardized  colors  and  because  it  can  be  put  down  and  picked  up  without  damaging 
most  surfaces.  The  corral  was  intended  to  be  a  square  of  red  construction  paper,  eight 
inches  per  side.  We  made  it  an  eight-inch  square  so  we  could  make  it  from  one  sheet  of 
construction  paper,  and  we  made  it  red  because  the  drag  sensor  would  be  able  to  easily 
distinguish  it  from  blue. 


68 


Fabricating  an  actual  carrying  case  was  outside  the  scope  of  the  project;  however, 
a  real  project  would  need  a  carrying  case  of  some  sort.  Shaped  foam  inserts  can  be 
custom  ordered  for  a  variety  of  hard  plastic  carrying  cases,  which  would  be  necessary  for 
a  device  made  from  a  kit  of  detachable  plastic  parts.  This  is  important  because  the  team 
discovered  that  when  transported  in  a  shoebox  in  checked  baggage  on  a  commercial 
airliner,  the  robot  invariably  fell  apart.  If  the  robot’s  exterior  fuselage  was  made  in  a 
single  piece,  like  it  would  be  on  a  real  system,  some  of  these  issues  could  be  mitigated. 

The  TCV  communicates  with  the  operator  control  unit  through  a  wireless 
transmission  control  protocol/Internet  protocol  (TCP/IP)  connection.  This  means  that  the 
fielded  configuration  for  the  TCV  requires  a  preconfigured  wireless  router  so  the  two 
devices  can  communicate.  This  is  not  necessary  for  the  ACV. 

The  ACV  and  TCV  were  both  tested  with  computer  maintenance  tools  available. 
The  team  had  the  ability  to  test  and  troubleshoot  issues  that  arose  during  testing. 
Although  the  end  user  would  not  be  able  to  do  this,  a  full  system  would  include  depot- 
level  and  factory-level  troubleshooting  tools.  To  simulate  this  support,  the  team  had  the 
ability  to  view  advanced  logs  and  make  bug  fixes  during  testing. 

F.  TELEOPERATED  SOFTWARE  DESIGN 

1.  TCV  State  Diagram 

The  State  diagram  helps  show  the  different  states  the  TCV  would  need  to  pass 
through  to  complete  a  clearing  mission.  Figure  3 1  is  the  state  diagram  for  the  TCV.  As 
can  be  seen  in  the  diagram,  the  system  initializes  and  connects  with  the  OCU  then 
proceeds  to  clearing,  then  ends.  Table  14  outlines  the  state  actions  and  transition  events 
of  the  TCV  state  diagram.  The  table  starts  with  an  initial  state  then  details  the  state 
actions  and  transition  events  that  the  TCV  may  experience  within  that  initial  state 
followed  by  the  next  state  related  to  the  state  actions  and  transition  events. 
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Figure  31.  TCV  State  Diagram 


Table  14.  TCV  State  Diagram  Actions 


State  No. 

Name 

State  Actions 

Transition  Event 

Next  State 

0 

Starting 

Operator  turns  on  robot.  LeJOS  boots 
up. 

leJOS  Boot  complete 

1 

1 

Initializing 

Operator  starts  the  TCV/TECHMAN 

OCU  software. 

TCV/TECHMAN  OCU 

Software  is  loaded  and  ready  for 

user  input 

2 

Unexpected  condition  detected. 

Robot  sends  error  code  or  fails  to 
initiate  desired  state. 

Appropriate  action  taken  to 
handle  condition. 

8 

2 

Placement 

Operator  places  robot  in  starting 
location.  Robot  is  placed  on  ground 
and  oriented  to  desired  direction 

Placement  Complete 

3 

Unexpected  condition  detected. 

Robot  sends  error  code  or  fails  to 
initiate  desired  state. 

Appropriate  action  taken  to 
handle  condition. 

8 

3 

OCU 

Establish 

Operator  press  connect  button  on 
OCU 

OCU  indicates  successful 
connection.  (Green) 

4 
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State  No. 

Name 

State  Actions 

Transition  Event 

Next  State 

Connectio 
n  w/TCV 

Unexpected  condition  detected. 

Robot  sends  error  code  or  fails  to 
initiate  desired  state. 

Appropriate  action  taken  to 
handle  condition.  (Red) 

8 

4 

Ready 

State 

Operator  directs  TCV  to  move 
towards  target 

TCV  arrives  at  target  location 

5 

TCV  closes  and  raises  claws 

TCV  has  captured  Vial 

6 

TCV  closes  and  raises  claws 

TCV  fails  to  capture  Vial 

8 

Area  cleared  of  all  vials 

TCV  has  captured  all  vials 

7 

Unexpected  condition  detected. 

Robot  sends  error  code  or  fails  to 
initiate  desired  state. 

Appropriate  action  taken  to 
handle  condition. 

8 

5 

Approach 

Target 

TCV  stops  at  target 

TCV  stopped  at  target  location 

4 

Unexpected  condition  detected. 

Robot  sends  error  code  or  fails  to 
initiate  desired  state. 

Appropriate  action  taken  to 
handle  condition. 

8 

6 

Return 

Target 

Operator  direct  TCV  to  corral 

Robot  deposits  vial  in  corral 

4 

Unexpected  condition  detected. 

Robot  sends  error  code  or  fails  to 
initiate  desired  state. 

Appropriate  action  taken  to 
handle  condition. 

8 

7 

Return  to 

User 

Robot  travels  back  towards  starting 
location  and  stops. 

Robot  is  stopped 

9 

Unexpected  condition  detected. 

Robot  sends  error  code  or  fails  to 
initiate  desired  state. 

Appropriate  action  taken  to 
handle  condition. 

8 

8 

Handling 

Exception 

s 

Take  appropriate  actions  to  handle 

exceptions 

Error/exception  cleared.  Robot 

ready  to  continue  mission 

1 

Actions  cannot  be  taken  to  resolve 
exception 

Mission  aborted 

9 

9 

End  State 

Mission  completed  or  aborted 

Following  development  of  the  state  diagram,  the  team  developed  an 

INNOSLATE  model  to  help  understand  the  needs  of  the  software  to  support  the  TCV. 

Figure  49  in  Appendix  A  shows  the  activity  diagram  developed  in  INNOSLATE.  The 

model  depicts  the  flow  of  data  as  the  TCV  completes  a  clearing  mission.  The  model 

allowed  the  team  to  run  some  different  scenarios  and  have  an  estimate  of  the  time 

required  to  complete  a  mission.  Following  the  model,  the  team  started  developing  the 

TCV  software.  The  model  depicts  the  flow  of  data  as  the  TCV  completes  a  clearing 

mission.  The  model  allowed  the  team  to  ran  some  different  scenarios  and  have  an 

estimate  of  the  time  required  to  complete  a  mission.  Following  the  model,  the  team 

started  developing  the  TCV  software.  The  model  depicts  the  flow  of  data  as  the  TCV 

completes  a  clearing  mission.  The  model  allowed  the  team  to  run  some  different 
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scenarios  and  have  an  estimate  of  the  time  required  to  complete  a  mission.  Following  the 
model,  the  team  started  developing  the  TCV  software.  The  model  depicts  the  flow  of  data 
as  the  TCV  completes  a  clearing  mission.  The  model  allowed  the  team  to  run  some 
different  scenarios  and  have  an  estimate  of  the  time  required  to  complete  a  mission. 
Following  the  model,  the  team  started  developing  the  TCV  software. 

2.  TCV  High-Level  Design 

The  OCU  command  and  control  software  resides  on  the  OCU.  The  software 
allows  form  automatic  robot  discovery  over  the  network,  automatic  sensor  initialization, 
and  automatic  positioning  of  the  claw.  The  software  provides  the  operator  with  control  of 
the  robot,  motor  speed  control,  and  provides  continuous  sensor  feedback  and 
visualization.  Figure  32  shows  a  visual  representation  of  the  OCU  software’s  data 
exchange  with  the  operator. 


Figure  32.  OCU  Software  Data  Exchange 


The  TCV  OCU  software  utilizes  a  two-layered  modular  architecture  designed  to 
optimize  for  reuse  of  existing  application  programing  interface  (API)s  and  functions  with 
minimal  complexity.  The  first  layer  is  the  user  interface,  which  displays  relevant 
information  to  the  operator  as  well  as  allows  commands  to  be  sent  to  the  TCV.  The  user 
interface  is  coupled  to  the  functional  component  layer,  which  is  a  series  of  software 
modules  responsible  for  processing  exchange  of  user  inputs  and  TCV  outputs.  The  OCU 
software  itself  runs  entirely  on  the  field  laptop  and  requires  no  additional  code  software 
to  be  loaded  onto  the  TCV  beyond  the  base  leJOS  operating  system.  This  is  achieved 
through  the  implementation  of  existing  leJOS  APIs  and  functions  that  are  provided  as 
part  of  the  leJOS  software  development  kit.  This  approach  reduced  complexity  by 
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limiting  the  software  footprint  and  potential  points  of  failure.  The  OCU  issues  commands 
and  receives  sensor  data  using  TCP/IP  over  a  standard  wireless  network  connection. 

G.  AUTONOMOUS  SOFTWARE  DESIGN 

1.  ACV  State  Diagram 

As  with  the  TCV,  the  State  diagram  helps  show  the  different  states  the  ACV 
would  need  to  pass  through  to  complete  a  clearing  mission.  Figure  33  shows  the  state 
diagram  for  the  ACV.  As  can  be  seen  in  the  diagram,  the  system  initializes  then  proceeds 
to  clearing  mission  and  finally  ends.  Table  15  outlines  the  state  actions  and  transition 
events  of  the  ACV  state  diagram.  The  table  starts  with  an  initial  state  then  tracks  to  the 
state  actions  and  transition  events  that  the  ACV  may  experience  within  that  initial  state 
followed  by  the  next  state  related  to  the  state  actions  and  transition  events. 


Figure  33.  ACV  State  Diagram 
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Table  15.  ACV  State  Diagram  Actions 


State  No. 

Name 

State  Actions 

Transition  Event 

Next  State 

0 

Starting 

Operator  turns  on  robot.  leJOS 

JOOtS  Up. 

leJOS  Boot  complete 

1 

Operator  starts  the 

ACV/TECHMAN  software. 

ACV/Tuchman  Software  is 
loaded  and  ready  for  user  input 

2 

1 

initializing 

Unexpected  condition  detected. 

Robot  sends  error  code  or  fails  to 
initiate  desired  state. 

Appropriate  action  taken  to 
landle  condition. 

10 

2 

Operator  places  robot  in  starting 
ocation.  Robot  is  placed  on  ground 
and  oriented  to  desired  direction 

Placement  Complete 

3 

Placement 

Unexpected  condition  detected. 

Robot  sends  error  code  or  fails  to 
initiate  desired  state. 

Appropriate  action  taken  to 
landle  condition. 

10 

Travel  to 

Operator  gives  start  command. 

Robot  travels  to  scan  position. 

Robot  reaches  scan  position 

4 

3 

scan 

position 

Unexpected  condition  detected. 

Robot  sends  error  code  or  fails  to 
initiate  desired  state. 

Appropriate  action  taken  to 
landle  condition. 

10 

Robot  rotates  90  deg.  CCW  and 
begins  scanning  in  2  deg. 
increments  until  it  identifies  a  target. 

Azimuth  oriented  towards 
center  of  identified  target. 

5 

4 

Scanning 

Robot  rotates  90  deg.  CCW  and 
begins  scanning  in  2  degree 
increments  until  it  rotates  360  deg. 
Without  identifying  a  target 

Scan  complete.  Rotate  90  Deg. 
CW  to  orient  towards  starting 
joint 

9 

Unexpected  condition  detected. 

Robot  sends  error  code  or  fails  to 
initiate  desired  state. 

Appropriate  action  taken  to 
landle  condition. 

10 

5 

Approach 

Robot  approaches  target  at  full 
speed  until  half  the  distance  to  the 
target  is  traversed.  Claws  open  and 
are  lowered. 

Robot  has  reached  half  the 
distance  to  target.  Claw  is 
lowered  and  open. 

6 

i  arget 

Unexpected  condition  detected. 

Robot  sends  error  code  or  fails  to 
initiate  desired  state. 

Appropriate  action  taken  to 
landle  condition. 

10 

6 

Closing  on 

Robot  approaches  the  target  at  half 
speed.  Robot  travels  remainder 
distance  plus  2  distance  units. 

Robot  has  reached  target  and 
displaced  target  two  distance 
units 

7 

Target 

Unexpected  condition  detected. 

Robot  sends  error  code  or  fails  to 
initiate  desired  state. 

Appropriate  action  taken  to 
landle  condition. 

10 

7 

Capturing 

Robot  captures  target  by  closing 
then  raising  the  claw.  Robot  orients 
jack  towards  corral 

Target  captured  and  robot 
oriented  for  return. 

8 

Target 

Unexpected  condition  detected. 

Robot  sends  error  code  or  fails  to 
initiate  desired  state. 

Appropriate  action  taken  to 
landle  condition. 

10 
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State  No. 

Name 

State  Actions 

Transition  Event 

Next  State 

8 

Return 

Target 

Robot  travels  back  towards  starting 
location.  Robot  opens  claws  and 
back  away  from  dropped  off  vial 
and  stops 

Robot  is  stopped  and  claws  are 
open 

1 

Unexpected  condition  detected. 
Robot  sends  error  code  or  fails  to 
initiate  desired  state. 

Appropriate  action  taken  to 
handle  condition. 

10 

9 

Return  to 
User 

Robot  travels  back  towards  starting 
location  and  stops. 

Robot  is  stopped 

11 

Unexpected  condition  detected. 
Robot  sends  error  code  or  fails  to 
initiate  desired  state. 

Appropriate  action  taken  to 
handle  condition. 

10 

10 

Handling 

Exceptions 

Take  appropriate  actions  to  handle 
exceptions 

Error/exception  cleared.  Robot 
ready  to  continue  mission 

1 

Actions  cannot  be  taken  to  resolve 
exception 

Mission  aborted 

11 

11 

End  State 

Mission  completed  or  aborted 

After  developing  the  ACV  state  diagram  the  developers  sought  to  understand  the 
operational  concept  as  it  relates  to  the  ACV.  Figure  34  shows  a  pictorial  representation  of 
the  ACV  operational  concept.  The  concept  shows  the  ACV  search  area,  the  allowed 
ultrasonic  sensor  range,  start  point,  scan  point,  vials  to  be  cleared,  and  the  clearing  path 
for  a  vial.  The  concept  along  with  the  state  diagram  gave  the  developers  a  visual  aid  to 
help  with  software  development. 
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2.  High-Level  Design 


The  TECHMAN  ACV  uses  a  three-layer  software  architecture.  The  software  at 
each  layer  is  provided  by  a  different  organization.  The  LEGO  Group  provides  the  EV3 
layer  software,  the  leJOS  project  provides  the  leJOS  layer,  and  Project  TECHMAN 
developed  the  TECHMAN  layer.  Software  at  a  higher  level  can  access  the  functionality 
provided  by  lower  layers  through  an  application  programming  interface,  but  lower  layers 
do  not  reach  into  higher  ones.  Figure  35  shows  the  three-layer  software  architecture. 


Observation 

Manager 


Orientation 

Manager 


Mission 

Manager 

(Decide) 


Action 

Manager 


JVM 


leJOS 

Library 


Utility 

Classes 


Kernel 


Smart  Brick  Sensor 

Firmware  Firmware 


Figure  35.  TECHMAN  Three-Layer  Software  Architecture 


Within  the  TECHMAN  layer,  the  different  parts  of  the  program  are  divided  into 
packages,  which  serves  as  a  secondary  layering  scheme.  The  Mission  Manager  can  reach 
to  its  “right”  and  order  the  robot  to  take  actions  (including  moving  the  robot,  raising  or 
lowering  the  claw,  and  causing  the  EV3  to  beep)  by  calling  methods  from  the  Action 
Manager,  or  it  can  reach  to  its  “left”  and  retrieve  information  about  the  robot’s  state 
(including  current  sensor  readings  and  the  memory  of  past  sensor  readings)  from  the 
Orientation  Manager.  The  Orientation  Manager  exposes  a  method  to  obtain  a  new  set  of 
current  sensor  readings  from  the  Observation  Manager,  which  can  be  called  on  demand 
by  the  Mission  Manager.  The  layers  are  designed  to  mimic  Col.  John  Boyd’s  OODA 
loop,  which  models  human  decision-making.  Under  OODA  theory,  the  decision  maker 
observes  something,  orients  themselves  to  what  they  saw  using  their  training  and 
experience,  decides  what  action  to  take,  and  acts  in  accordance  with  their  decision. 
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The  “business  logic”  of  the  robot’s  code  is  contained  in  the  Mission  Manager, 
which  implements  Boyd’s  Decision  step.  The  other  classes  can  be  seen  as  supporting  the 
Mission  Manager.  The  ACV  supports  loading  five  missions  simultaneously,  although 
only  one  can  be  executed  at  a  time. 

The  TECHMAN  ACV  prototype,  as  tested,  has  five  missions  loaded, 

“Four  By  Four”  and  four  diagnostic  missions.  In  FourBvFour,  the  ACV  drives  to  the 
center  to  do  a  360-degree  scan.  In  two  diagnostic  missions,  the  robot  drives  a  set  distance 
at  full  and  half  speed,  respectively.  In  the  other  two  diagnostic  missions,  the  robot  rotates 
a  set  distance.  The  diagnostic  missions  are  intended  to  be  used  in  finding  the  robot’s 
“trim  values,”  that  is,  the  adjustments  needed  to  be  made  between  ACV-measured 
“distance  units”  and  real  life  distance  traveled.  They  were  also  useful  for  testing  the 
capabilities  of  the  device  during  some  of  our  formal  testing. 

3.  The  Observe  and  Orient  Layers 

The  Observe  and  Orient  layers  have  high  cohesion  between  them,  which  enables 
them  to  work  well  together.  Roughly  speaking,  the  Observe  layer  is  responsible  for 
polling  the  current  state  of  the  sensors  and  the  Orient  layer  is  responsible  for  keeping 
track  of  the  ACV’s  state.  For  example,  consider  the  question  of  whether  the  robot  is 
within  the  target  area.  Through  the  Observation  Manager,  the  drag  color  sensor  can  be 
queried  to  see  if  the  device  is  currently  driving  past  the  blue  line  that  denotes  the  end  of 
the  target  area.  The  Orientation  Manager  tracks  the  number  of  times  the  robot  has  crossed 
a  blue  line.  Since  the  robot  starts  outside  the  box,  if  the  number  of  line  crossings  is  even, 
the  robot  is  outside  the  box  (because  it  crossed  into  the  box,  then  crossed  back  out).  If  the 
number  of  line  crossings  is  odd,  the  robot  is  inside  the  box  (because  it  has  not  crossed  out 
of  the  box  since  the  last  time  it  entered).  The  Orientation  Manager  can  be  queried  on 
whether  the  device  is  in  the  target  area  based  on  this  information. 

Most  methods  within  the  Orientation  Manager  are  very  specific  to  the  algorithms 
used  by  the  ACV.  In  addition  to  the  target  area  querying  described  above,  when  the  robot 
is  locked  on,  the  Orientation  Manager  tracks  the  number  of  hits  on  the  current  target.  This 
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is  for  use  in  the  target  detection  algorithm.  The  ACV  should  be  pointed  at  the  middle  of 
the  target  when  it  drives  up  and  grabs  the  vial.  To  do  this,  the  program  makes  sure  the 
device  finds  the  “near”  edge  of  the  vial,  then  makes  very  small  turns  (approximately  two 
degrees  in  the  current  setting)  until  it  can  no  longer  see  the  “far”  edge.  It  then  uses  the 
number  of  scans  and  the  angle  of  the  turns  to  calculate  the  wedge  during  which  the  target 
was  visible.  The  device  then  turns  back  to  the  center  of  that  wedge  so  it  can  approach  the 
target. 

The  Observation  Manager  and  Orientation  Manager  communicate  through  a  data 
structure  called  the  Sensor  Reading,  which  stores  readings  for  all  four  sensors  in  a  single 
object.  Sensor  Reading  objects  are  passed  to  the  Orientation  Manager,  which  can  use 
simple  queries  to  retrieve  the  data. 

Early  versions  of  the  ACV  would  have  the  Orientation  Manager  save  multiple 
objects  and  do  calculations  on  several  Sensor  Readings  at  a  time.  However,  this 
eventually  became  too  complex.  The  team  decided  to  simplify  the  Orientation  Manager 
and  store  only  the  information  that  was  immediately  mission  relevant.  For  example,  more 
recent  versions  of  the  ACV  do  not  store  every  color  reported  by  the  drag  sensor.  Instead, 
there  is  a  counter  that  indicates  whether  the  device  is  in  the  target  area. 

4.  The  Action  Layer 

The  Action  Manager  controls  the  physical  hardware  of  the  ACV.  It  can  be  divided 
into  three  major  sections,  the  drive  train,  the  end  effector,  and  the  smart  brick.  The  Action 
Manager  is  implemented  as  a  series  of  static  methods,  each  of  which  result  in  the  robot 
creating  a  specific  “output”  such  as  driving  forward,  lowering  the  claw,  or  generating 
sounds  using  the  buzzer.  The  actions  in  the  Action  Manager  are  stateless.  They  are 
compatible  with  being  called  in  any  order  while  the  device  is  running. 

The  easiest  part  of  the  action  manager  to  understand  is  the  end  effector  controls, 
which  are  used  to  raise  and  lower  the  claw.  Specifically,  there  is  one  method  to  raise  the 
claw  all  the  way  and  a  second  method  to  lower  the  claw  all  the  way.  Grasping  the  claw 
shut  is  the  first  part  of  raising  the  claw,  and  opening  the  claw  is  the  last  part  of  lowering 
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it.  Due  to  the  hardware  modifications  made  to  the  device’s  claw,  attempting  to  raise  a 
claw  already  in  the  top  position  or  attempting  to  lower  a  claw  in  the  lowered  position  will 
not  harm  the  robot.  Logically,  it  is  the  response  of  the  Mission  Manager  and  Orientation 
Manager  to  track  the  claw’s  state. 

The  next  functions  of  the  Action  Manager  are  the  actions  related  to  the  buzzer  and 
the  lights  on  the  smart  brick.  These  functions  could  be  used  to  send  visual  or  auditory 
output  to  the  user.  These  functions  are  thin  wrappers  around  functions  provided  by  the 
leJOS  environment,  which  in  turn  wrap  functions  provided  by  the  hardware.  The  final 
functions  of  the  Action  Manager  are  the  drivetrain  methods,  which  wrap  functions 
provided  by  the  leJOS  Differential  Pilot  class  in  the  same  way. 

5.  The  Mission  Layer 

The  Orientation  Manager  is  a  representation  of  the  device’s  state,  and  the  Action 
Manager  is  a  representation  of  the  potential  actions  the  robot  can  take.  The  link  between 
“When  the  device  is  in  state  X,  take  action  Y”  is  located  in  the  Mission  Manager. 

A  different  Mission  Manager  represents  each  of  the  potential  sets  of  instructions 
the  ACV  can  take.  At  startup,  the  user  selects  the  Mission  Manager  they  would  like  to 
control  the  robot  for  that  mission. 

The  Mission  Layer  fulfills  Boyd’s  “decide”  step.  The  team  decided  to  call  it 
“Mission”  rather  than  “Decide”  because  it  implicitly  tracks  a  different  kind  of  state  than 
the  Orientation  Manager  does.  The  Orientation  Manager  tracks  the  state  of  the  device 
relative  to  its  physical  environment.  The  Mission  Manager  tracks  the  specific  instructions 
given  to  the  device  (in  other  words,  the  mission),  pending  instructions,  and  estimated 
instruction  completion  time. 

There  are  three  functional  missions,  which  the  ACV  is  programmed  to  execute,  as 
well  as  two  for  debugging  purposes.  The  three  functional  missions  send  the  ACV  into  the 
target  area,  have  it  drive  to  the  scan  point  (a  specific  distance  from  the  start  point),  and 
have  it  rotate  while  scanning  until  it  finds  a  target.  The  ACV  then  approaches  the  target, 
grabs  it,  returns  to  the  scan  point,  and  then  returns  to  the  start  point. 
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The  FourByFour  mission  starts  from  the  middle  of  the  target  area  and  scans  360 
degrees.  The  LeftCorner  and  RightCorner  missions  start  from  a  comer  of  the  target  area 
and  scans  90  degrees. 

The  debugging  missions  have  the  robot  drive  a  set  distance  and  rotate  a  set 
distance,  respectively.  These  are  used  for  calibrating  the  Differential  Pilot  Adapter. 

An  action  diagram  depicting  the  FourByFour  mission  is  shown  in  Figure  50, 
Figure  51,  and  Figure  52  of  Appendix  B. 

6.  The  Support  Classes 

In  addition  to  the  four  architectural  layers,  there  are  also  several  support  classes. 
Support  classes  are  accessible  from  most  places  in  the  code  and  are  designed  for  things 
that  do  not  fit  into  the  OODA  framework.  For  example,  the  startup  code  and  the 
SlightlySmarterMenu  class  are  support  classes.  The  SlightlySmarterMenu  class  runs  on 
startup  and  waits  for  user  input.  It  is  named  that  because  it  uses  TECHMAN-designed 
wrappers  around  the  input  button  functionality  in  leJOS.  In  several  places,  leJOS  uses 
“numerical”  enums  for  things  that  are  not  logically  numbered,  such  as  which  button  is 
pressed. 

The  other  primary  support  class  is  the  logging  functionality.  The  Logger  has 
functionality  designed  to  show  or  hide  messages  when  the  program  is  run  at  different 
levels.  For  example,  at  the  most  restrictive  priority  level,  RUNNING,  only  messages 
marked  “RUNNING”  are  displayed  to  the  user.  Each  instruction  to  create  a  log  entry  is 
assigned  a  priority  when  the  code  is  written,  and  the  log  priority  level  can  be  set  to 
different  values  in  different  areas  of  the  code.  For  example,  when  debugging  an  issue 
with  the  Mission  Manager,  if  all  the  other  areas  of  the  code  are  set  to  RUNNING,  but  the 
Mission  Manager  logging  is  set  to  DEBUG,  all  messages  except  the  Mission  Manager 
messages  will  be  suppressed.  This  aids  in  debugging. 
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H.  OPERATION 


1.  Mission  Preparation 

Mission  preparation  begins  with  designation  of  an  area  to  be  cleared.  Once 
identified,  the  area  must  be  cordoned  off  using  the  included  blue  painter’s  tape  and 
measuring  tape.  The  cordoned  off  area  must  be  a  four  foot  by  four  foot  square.  After  the 
area  has  been  prepared,  execution  of  the  clearance  mission  will  proceed  in  accordance 
with  either  the  teleoperated  or  autonomous  vehicle  operation  instructions.  The  following 
sections  2  and  3  outline  operational  instructions  for  the  UGVs. 

2.  Teleoperated  Operation 

Once  ready  for  operations,  unpack  the  robot  from  the  transport  case.  Install 
charged  batteries  into  the  EV3  brick.  Next,  power  on  the  field  laptop  followed  by  the 
included  wireless  access  point.  Once  the  field  laptop  has  finished  starting  up,  the  user 
must  launch  the  TCV  OCU  software  and  confirm  the  laptop  has  connected  to  the  wireless 
access  point.  Finally,  turn  on  the  robot  by  pressing  the  power  button.  The  robot  will 
automatically  connect  to  the  wireless  access  point  once  it  has  finished  powering  up. 

The  TCV  OCU  software,  displayed  in  Figure  36,  allows  for  control  of  the  robot 
and  visualization  of  sensor  data  once  a  connection  is  established.  Pressing  the  OCU 
software’s  connect  button  will  begin  the  automated  connection  and  initialization 
process.  Once  the  connection  process  has  begun,  the  robot  will  emit  a  series  of  beeps  to 
indicate  the  OCU  has  successfully  connected  and  initialized  the  robot.  The  system  is 
ready  for  operation  once  the  robot  emits  three  consecutive  beeps.  In  addition  to 
movement  and  claw  control,  the  OCU  software  allows  for  adjustments  to  the  turning  and 
driving  speed  of  the  robot  as  well  as  individual  trim  of  the  left  and  right  drive  motors  for 
calibration.  The  OCU  software  also  provides  feedback  from  the  robot’s  color,  distance, 
and  touch  sensors. 

Finally,  before  proceeding  with  its  mission,  the  robot  must  be  placed  at  the  edge 
of  the  area  to  be  cleared.  Drive  the  system  into  the  target  area,  grab  a  vial,  and  bring  it 
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back  to  the  corral.  Continue  this  until  all  the  vials  are  cleared.  When  the  mission  is 
complete  shut  down  the  system,  remove  the  batteries,  and  place  in  transport  container. 


Figure  36.  TCV  OCU  Software  Graphical  User  Interface 

3.  Autonomous  Operation 

Once  ready  for  operations  unpack  the  robot  from  the  transport  case.  Install 
charged  batteries  into  the  EV3  brick.  Turn  on  the  robot  by  pressing  the  power  button. 

Once  the  device  is  running,  select  the  commands  to  run  the  program 
OODALoop.jar.  Once  the  program  is  running,  select  the  FourByFour  mission  using  the 
button  in  the  center  of  the  keypad. 

Place  the  device  on  the  edge  of  the  area  to  be  cleared.  The  device  will  drive  into 
the  target  area,  grab  the  vial,  and  bring  it  back  to  its  start  point,  and  then  the  program  will 
end.  If  there  are  multiple  vials,  run  the  OODA  Loop.jar  program  once  for  each  vial. 

Once  all  the  vials  are  cleared,  remove  the  batteries  and  place  in  transport  container. 
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VI.  TEST  AND  EVALUATION 


A.  MEASURES  OF  EFFECTIVENESS 

Measures  of  effectiveness  (MOE)  and  measures  of  performance  (MOP)  were  used 
to  detennine  how  well  the  TECHMAN  ACV  and  TCV  solved  the  customer’s  problem 
and  how  well  each  UGV  component  performed  in  doing  so. 

MOEs  were  used  to  measure  the  effect  (mission  accomplishment)  that 
came  from  the  use  of  the  system  in  its  expected  environment.  That 
environment  included  the  system  under  test  and  all  interrelated  systems, 
that  is,  the  planned  or  expected  environment  in  tenns  of  sensors,  command 
and  control,  and  platfonns,  as  appropriate,  needed  to  accomplish  an  end- 
to-end  mission.  (DAU  2012) 

MOPs  are  system-particular  perfonnance  parameters  such  as  speed, 
payload,  range,  time -on-station,  frequency,  or  other  distinctly  quantifiable 
performance  features.  (DAU  2012) 

Table  17  contains  the  MOEs  for  the  TECHMAN  family  of  vehicles  (FOV). 

B.  TEST  PLAN 

Testing  was  perfonned  at  Aberdeen  Proving  Ground,  MD  from  5  September 
through  7  September  2015.  The  TECHMAN  team  provided  the  facilities, 
instrumentation,  test  support  equipment,  and  personnel  required  to  perform  testing.  All 
test  data  and  the  test  team  recorded  incidents.  A  summary  of  the  test  objectives  is 
presented  in  Table  16. 
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Table  16.  Sub  tests  and  Objectives 


Subtest 

Objective 

Physical 

Characteristics 

Determined  the  physical  dimensions,  weight,  and  center  of  gravity 
measurements  for  the  TECHMAN  (FOV) 

Performance 

Characteristics 

Determined  whether  the  system  performance  characteristics  of  the 
TECHMAN  FOV  met  the  requirements 

Standard  Nominal 
Clearing  Test 

Determined  the  capability  of  the  TECHMAN  FOV  to  clear  a  standard 
test  area. 

Non-Standard 

Clearing  Test 

Determined  the  capability  of  the  TECHMAN  FOV  to  clear  a  Non- 
Standard  test  area. 

Table  17  shows  the  Data  Source  Matrix  for  the  TECHMAN  FOV.  The  table  links 
the  requirements  with  the  MOEs  and  test  events. 


Table  17.  TECHMAN  Family  of  Vehicles  Data  Source  Matrix 


Operational 

Task 

Req  # 

Requirement 

MOE 

Physical 

Characteristics 

Performance 

Characteristics 

Standard  Nominal 
Clearing  Test 

Non-Standard 
Clearing  Test 

Operational  Task 

1 :  The  Robot  shall 
pass  and  receive 
mission 
information 

KSA  1 

The  robot  shall  notify 
the  operator  of 
system  malfunctions. 

T=0 

System  malfunctions 
will  be  recorded. 
Notifications  of 
malfunctions  from  the 
system  will  be  noted. 

The  actual 
malfunctions  and 
notifications  of  those 
will  be  compared  to 
check  effectiveness 

X 

X 

X 

KSA  2 

The  robot  shall  store 
a  mission  log  file  for 
retrieval  by  the 
operator. 

T=0 

Log  files  will  be 
downloaded  and 
checked  for  correctness 

X 

X 

X 

KSA  3 

When  returning  a  vial 
to  the  corral,  the 
robot  shall  play  a 
distinct  sound  for  a 
“hazardous  vial”  and 
a  different  sound  for 
an  inert  vial. 

T=0 

Operators  will  check 
vials  that  have  been 
returned 

X 

X 

Operational  Task 

2:  The  Robot  shall 
operate  in  its 
intended 
environment 

KPP  1  - 

Energy 

Starting  with  fully 
charged  batteries,  the 
robot  shall  run  for  the 
specified  amount  of 
time  without 
swapping  batteries. 

T:  2  hours, 

0:  3  hours 

Operator  will  run  robot 
until  batteries  are  no 
longer  able  to  power 
the  robot.  The  time  will 
be  recorded 

X 

KPP  2  - 
Transport 

The  system  shall  be 
transportable  in  the 
specified  number  of 
containers;  each 
container  shall  be 
transportable  by  a 
single  Solder. 

T:  Two 
containers, 
with  the 
weight  of 
each 

container 

not  to 

System  weight  and 
dimensions  will  be 
checked  and  recorded 

X 
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exceed  35 

lbs. 

0:  One 
container, 
with  a 
weight  not 
to  exceed  35 
lbs. 

KSA  4 

6  A  A  batteries  or 
rechargeable 
equivalent  shall 
power  the  robot. 

T=0 

Batteries  will  be 
checked 

X 

KSA  5 

The  system  shall 
operate  in  a  manner 
safe  to  its  operators. 

T=0 

Any  unsafe  operations 
or  actions  will  be 
recorded 

X 

X 

X 

X 

APA  1 

Batteries  shall  be 
replaceable  within 
two  minutes. 

T=0 

Operator  will  check  for 
replacement  time 

X 

APA  2 

The  system  shall 
comply  with  the 

FCC’s  requirements 
for  a  Class  D  device. 
Harmful  interference, 
as  defined  in  the  FCC 
rules,  shall  not 
prevent  the  system 
from  accomplishing 
the  mission. 

T=0 

System  certificates  will 
be  checked  for 
compliance 

X 

APA  3 

The  system  shall  be 
operated  by  not  more 
than  one 
servicemember 

T=0 

Operation  by  a  single 
operator  will  be 
checked 

X 

X 

Operational  Task 

3:  The  Robot  shall 
propel  itself  under 
its  own  power, 
including  while 
carrying  vials 

KSA  6 

The  robot  shall 
traverse  terrain  of 
smooth  concrete  or 
blacktop  surfaces 

T:  Concrete 
or  blacktop 
with 

coefficient 
of  friction 
between  0.2 
-0.9 

0:  Gravel  or 
forest  floor 

The  system  will  be 
checked  for  ability  to 
traverse  terrain.  Any 
limitations  will  be 
recorded 

X 

X 

X 

KSA  7 

The  robot  shall  be 
able  to  change  its 
heading  to  any  360 
degree  orientation 

T=0 

Maneuverability  will 
be  check  and  any 
limitations  will  be 
recorded 

X 

X 

X 

Operational  Task 

4:  The  Robot  shall 
clear  a  given  area 
of  radiological 
threats 

KPP3- 

Clearing 

Area 

The  robot  shall  clear 
a  rectangular  area 
(the  “target  area”)  of 
a  defined  size. 

T:  16  square 
feet 

0:  625 
square  feet 

Ability  to  clear  the 
entire  target  area  of 
vials  will  be  checked 

X 

X 

KPP4- 

Vial 

Transport 

The  robot  shall 
secure  all  vials  and 
return  them  to  the 
corral  for  disposal  by 
trained  personnel  and 
a  separate  system  at 
the  required  rate. 

T:  P(retum 
standard 
size  vial)  = 
95% 

0:  P(retum 
standard 
size  vial)  = 

Ability  of  the  robot  to 
transport  vials  to  the 
corral  will  be  checked 

X 

X 
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99% 

KSA  8 

The  robot  shall 
distinguish  a 
“hazardous”  colored 
vial  from  vials  of 
other  colors  with  a 
specific  probability 
of  distinction. 

T: 

P(distinction 
):  90% 

O: 

P(distinction 
):  95% 

Operators  will  check 
vials  that  have  been 
returned  and  record 
results 

X 

X 

X 

KSA  9 

The  system  shall 
detect  vials  under 
fluorescent  lighting 
conditions  (between 
2000  and  900 
lumens). 

T=0 

System  operation  will 
be  check  and  any 
limitation  will  be 
recorded 

X 

X 

X 

KSA  10 

A  continuous  blue 
marking  not  less  than 

1  inch  thick  shall 
surround  the  target 
area. 

T=0 

X 

X 

KSA  11 

The  start  and  end 
point  for  the  robot 
shall  be  a  12”  by  48” 
red  colored  tile  called 
the  corral.  The  corral 
shall  be  located  at  the 
edge  of  the  target 
area. 

T=0 

Test  course  will  be 
checked  for  proper 
layout 

X 

X 

KSA  12 

The  system  shall 
have  the  specified 
probability  of 
completing  a  2 
mission  hours 
without  an  essential 
function  failure. 

T:  0.75 

Probability 

of 

completing 

a  2  hour 

mission 

without  an 

essential 

function 

failure 

O:  0.9 

Probability 

of 

completing 

a  2  hour 

mission 

without  an 

essential 

function 

failure 

Any  anomalies  during 
testing  will  be  recorded 
and  used  to  determine 
the  reliability.  All  test 
events  will  be  time 
stamped  from  start  to 
stop  and  the  time  of 
anomalies  will  be 
recorded 

X 

X 

X 
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KSA  13 

The  system  shall 
have  the  specified 
probability  of 
completing  2  mission 
hours  without  a 
system  abort 

T:  0.95 

probability 

of 

completing 
a  2  hour 
mission 
without  a 
system  abort 
0:  0.99 
probability 
of 

completing 
a  2  hour 
mission 
without  a 
system  abort 

Any  anomalies  during 
testing  will  be  recorded 
and  used  to  determine 
the  reliability.  All  test 
events  will  be  time 
stamped  from  start  to 
stop  and  the  time  of 
anomalies  will  be 
recorded 

X 

X 

X 

APA  4 

The  system  shall  not 
exceed  the  specified 
MMH/OH  ratio 

T:  0.04 
MMH/OH 

O:  0.015 
MMH/OH 

Any  anomalies  during 
testing  will  be  recorded 
and  used  to  determine 
the  reliability.  All  test 
events  will  be  time 
stamped  from  start  to 
stop  and  the  time  of 
anomalies  will  be 
recorded 

X 

X 

X 

APA  5 

The  system  shall  pass 
the  Standard 

Nominal  Test  Pattern 
according  to  the 
threshold  and 
objective  values 
defined  by  that  test 
pattern. 

T:  See  the 
SNTP 

O:  See  the 
SNTP 

The  system  will  be 
checked  for  the  ability 
to  complete  the  SNTP 
in  15  minutes  or  less 

X 

1.  Physical  Characteristics 

a.  Objective 

•  Measured  the  physical  dimensions  (length,  width,  height,  etc.),  weight,  and 
center  of  gravity  measurements  of  the  TECHMAN  ACV  and  TCV. 

•  Detennined  whether  the  TECHMAN  FOV  exhibits  good  human  engineering 
design  characteristics. 
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Criteria  and  Data  Analysis 


The  results  of  the  physical  dimensions,  weight,  and  center  of  gravity 
measurements  of  the  TECHMAN  ACV  and  TCV  were  used  to  determine  the 
transportability  of  the  TECHMAN  FOV.  The  measurements  also  provided 
input  to  the  safety  analysis  and  ability  of  the  5th  to  95th  servicemember  to 
operate  the  systems.  This  portion  of  the  physical  characteristics  provided  input 
to  evaluation  of: 

•  KPP  2 

•  KSA  5 

The  results  of  the  general  design  fit  and  finish  and  battery  placement  of  the 
TECHMAN  ACV  and  TCV  were  used  to  determine  time  required  for  battery 
replacement  and  number  of  batteries.  This  portion  of  the  physical 
characteristics  provided  input  to  evaluation  of: 

•  KSA  4 

•  APA  1 

The  results  of  the  human  engineering  design  characteristics  were  used  to 
detennine  ease  of  use  of  the  controls,  displays,  and  labeling.  This  portion  of 
the  physical  characteristics  provided  input  to  the  evaluation  of: 

•  KSA  1 

•  KSA  5 

Test  Procedures  and  Data  Required 

Physical  Dimensions  -  Physical  dimensions  of  the  TECHMAN  ACV  and 
TCV  were  measured  using  steel  tapes,  levels,  and  calipers  while  the  system  is 
positioned  on  a  hard  level  surface. 

Weight  -  The  TECHMAN  ACV  and  TCV  weight  was  measured  with 
batteries  installed  and  all  mission  essential  equipment  attached.  The  weight  of 
the  system  was  measured  using  a  calibrated  digital  scale. 
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•  Rollover  Threshold  -  Rollover  Threshold  was  measured  by  placing  the 
TECHMAN  ACV  and  TCV  on  a  flat  surface  with  an  inclinometer  attached. 
The  flat  surface  was  raised  until  a  load  shift  occurred.  The  ACV  and  TCV 
were  tilted  about  their  roll  axis.  Testers  insured  the  system  was  being  caught 
once  the  rollover  threshold  has  been  reached. 

•  Design  -  The  TECHMAN  ACV  and  TCV  was  timed  for  depleted  battery 
removal  and  charged  battery  install.  Any  noteworthy  design  issues  were 
recorded. 

•  Controls,  Displays,  and  Labeling  -  All  controls,  displays,  and  labeling  were 
inspected  with  respect  to  human  factors  engineering  (HFE). 

The  following  data  were  recorded: 

•  physical  dimensions 

•  weight 

•  rollover  threshold 

•  design  and  battery  system 

•  human  factors  engineering  measurements 

•  photographs 

d.  Physical  Characteristics  Results 

Figure  37  shows  the  RCV  on  the  scale  being  used  to  obtain  weight  measurements. 
Figure  38  and  Figure  39  show  two  views  of  the  rollover  and  slip  angle  apparatus.  The 
board  was  raised  until  the  robot  either  tipped  or  slipped.  The  coefficient  of  friction 
between  the  robots  and  wood  is  approximately  0.7  to  1.0.  The  results  of  the  physical 
characteristics  testing  can  be  seen  in  Table  18.  With  regards  to  slip  angle  and  rollover 
angle,  the  robots  would  slip  before  the  rollover  threshold  occurred  except  when  the  robot 
rear  was  facing  down  slope.  Both  the  ACV  and  TCV  would  tip  before  slipping  in  this 
orientation.  However,  once  the  tip  occurs  the  robots  would  rest  against  the  rear  color 
sensor,  which  prevented  the  robots  from  completely  rolling  over. 
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Table  18.  Physical  Characteristics 


Parameter 

ACV 

TCV 

Length  (inches) 

11 

10.5 

Width  (inches) 

6.25 

6.25 

Height  (inches) 

6.625 

6.125 

Weight  (pounds) 

6.07 

6.06 

Rollover  Left  (degrees) 

46 

46 

Rollover  Right  (degrees) 

45 

44 

Rollover  Front  (degrees) 

43 

42 

Rollover  Rear  (degrees) 

19 

19 

Slip  Angle  Left  (degrees) 

27 

25 

Slip  Angle  Right  (degrees) 

28 

28 

Slip  Angle  Front  (degrees) 

28 

30 

Slip  Angle  Rear  (degrees) 

NA 

NA 

Figure  37.  RCV  on  Scale 
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Figure  38.  Rollover  Threshold  Test  Apparatus  View  1 


or.-.. 


Figure  39.  Rollover  Threshold  Test  Apparatus  View  2 


The  operators  were  able  to  change  the  six  rechargeable  batteries  within  two 
minutes. 

The  robots  have  pinch  points  around  the  claw  and  tracks.  However,  no  pinch 
points  have  the  capability  of  causing  serious  injury.  No  other  adverse  HFE  issues  were 
found  with  the  systems.  Figure  40  shows  characteristic  photos  of  the  robot. 
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Figure  40.  Different  Views  of  the  TECHMAN  UGV 


2.  Performance  Characteristics 

a.  Objective 

•  Determined  whether  the  TECHMAN  FOV  performance  characteristics  met 
the  requirements  of  the  TECHMAN  CDD. 

b.  Criteria  and  Data  Analysis 

The  results  of  the  performance  characteristics  were  used  to  determine  the 
performance  and  safety  of  the  TECHMAN  ACV  and  TCV.  The  perfonnance 
characteristics  provided  input  to  evaluation  of: 

•  KSA  1-3 

•  KPP  1 

•  KSA  5 

•  KSA  6-9 

•  KPP  4 

•  APA  3 
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c.  Test  Procedures  and  Data  Required 

•  Top  Speed  -  The  top  speed  of  the  TECHMAN  FOV  were  determined  by 
recording  the  time  it  took  for  the  system  to  travel  20  feet  in  both  the  forward 
direction  and  reverse  direction.  The  test  was  performed  with  batteries  with  at 
least  90%  charge.  The  test  took  place  on  representative  smooth  concrete. 

•  Turning  ability  (Differential  Piloting)  -  The  ability  of  the  TECHMAN  FOV  to 
change  its  heading  to  any  360-degree  orientation  was  determined  by  using  the 
systems  differential  piloting  on  representative  smooth  concrete.  The  test  team 
recorded  the  amount  of  time  required  to  turn  180  degrees  and  360  degrees. 
The  ACV  was  checked  for  its  ability  to  maintain  awareness  of  the  degrees 
turned.  The  system  tracks  and  driveline  were  inspected  for  any  issues  or  wear. 

•  Terrain  -  The  ability  of  the  TECHMAN  FOV  to  cross  smooth  concrete  tile 
and  carpet  was  detennined  maneuvering  the  system  in  a  figure  eight  pattern 
on  representative  concrete.  Subjective  observations  were  made  by  the  test 
team  of  the  system’s  ability  to  traverse  the  terrain.  The  system  tracks  and 
driveline  were  inspected  for  any  issues  or  wear. 

•  Sensor  Systems  -  The  TECHMAN  FOV  sensor  systems  functionality  was 
determined  by  checking  for  proper  operation.  These  tests  proved  operation  of 
the  sensor  itself,  mounting  position,  and  ability  of  the  software  to  recognize 
and  interpret  sensor  input.  Three  different  sensors  where  tested: 

o  Color  -  The  color  sensor’s  abilities  were  determined  by  checking  the 
ability  to  find  the  blue  marking  one  inch  wide  and  one  foot  long  on  the 
representative  concrete.  The  color  sensors  ability  was  also  detennined 
by  checking  the  ability  to  distinguish  between  a  hazardous  vial  (green) 
and  non-hazardous  vial  (gray).  The  color  sensors  ability  was  tested 
under  fluorescent  lighting. 

o  Ultra-sonic  -  The  ultra-sonic  sensor’s  ability  was  determined  by 
placing  a  vial  in  front  of  the  system  and  moving  TECHMAN  until 
system  notified  the  operator  a  vial  is  in  sight.  This  test  was  performed 
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putting  the  vial  at  the  extremes  of  the  advertised  sight  cone  of  the 
sensor.  Once  sighted  the  vial  distance  from  the  sensor  and  degrees  off 
the  centerline  of  the  sensor  were  recorded. 

o  Touch  Sensor  -  The  ability  of  the  touch  sensor  was  determined  by 
raising  the  vial  lift  arms  until  the  sensor  was  depressed  and  indicated 
to  the  system  that  the  arms  were  lifted. 

•  Operational  Time  -  The  operational  time  of  the  TECHMAN  FOV  was 
detennined  by  recording  the  amount  of  time  the  system  operated  starting  with 
fully  charged  batteries.  The  system  was  driven  while  performing  various 
operational  tasks  for  two  hours.  The  system  operational  time  test  was 
performed  on  smooth  concrete. 

•  System  Autonomy  (ACV)  -  The  autonomous  ability  of  the  TECHMAN  ACV 
was  detennined  by  having  the  system  start  at  a  blue  marking  one  inch  wide 
and  one  foot  long  then  maneuvering  on  its  own  to  another  blue  marking  four 
feet  away,  turning  180  degrees  and  returning  to  the  starting  location.  The 
system  autonomy  test  was  performed  on  smooth  concrete. 

•  Locating,  Lifting,  Transporting  Vials  -  The  ability  of  the  TECHMAN  FOV  to 
locate,  lift,  and  transporting  was  detennined  by  placing  the  various  sized  vials 
four  feet  in  front  of  the  system.  The  system  would  maneuver  to  the  vial  and 
lift  the  vial  then  return  to  its  starting  location.  The  testers  checked  for  the 
secureness  of  the  vial  while  in  the  lift  arms. 

The  following  data  were  recorded: 

•  time  to  travel  20  feet  (forward  /  reverse) 

•  time  to  turn  (Differential  Piloting) 

•  ability  to  cross  terrain 

•  ability  to  detect  marking  line 

•  ability  to  distinguish  vials 

•  functionality  of  lift  arm  sensor 

•  ability  of  lift  arm 
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•  operational  time  with  fully  charged  batteries 

•  ability  of  the  ACV  to  start  maneuver  and  return  to  the  same  location 

•  any  issues  or  faults  with  the  system 

•  photographs 

d.  Performance  Characteristics  Results 

Figure  41  shows  the  test  setup  to  test  the  time  to  travel  20  feet.  The  ACV  and 
TCV  at  100%  power  completed  the  20-foot  distance  in  29  seconds.  Reverse  speed  of  the 
systems  in  the  same.  The  operator  can  adjust  the  speed  of  the  TCV,  the  test  was  ran  at 
50%  speed  setting,  which  allowed  the  TCV  to  complete  the  20-foot  distance  in  56 
seconds. 


Figure  41.  20-Foot  Travel  Test 
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Both  the  ACV  and  TCV  were  able  to  change  their  heading  to  any  360° 
orientation.  Both  also  had  nearly  identical  time  to  perform  a  zero  radius  turn.  A  180°  turn 
took  approximately  one  second  and  360°  turn  took  approximately  two  seconds.  The  TCV 
and  ACV  also  proved  its  ability  to  traverse  concrete,  tile,  wood,  and  carpet  with  any 
adverse  effects  by  driving  in  a  figure  eight  pattern.  No  adverse  wear  was  observed  on  the 
tracks  or  drive  motors. 

While  both  the  ACV  and  TCV  have  color  sensors  mounted  with  the  intended 
ability  to  detect  a  marking  line  and  distinguish  vials,  neither  system  was  mature  enough 
to  use  those  sensors.  Because  of  this,  neither  system  was  able  to  detect  a  marking  line  or 
distinguish  vials.  Future  systems  may  gain  this  capability  but  the  current  systems  do  not 
and  therefore  do  not  meet  the  CDD  requirement  as  written. 

The  lift  ann  and  claw  system  were  tested  with  small  and  large  vials.  As  long  as 
the  vials  are  within  the  robots  open  claw  the  UGVs  have  no  trouble  picking  up  the  vials. 
The  lift  arm  sensor  functioned  as  intended  and  the  vials  were  held  securely  within  the 
claws.  The  ACV  system  is  able  to  successfully  locate  and  retrieve  a  vial  placed  four  feet 
in  front  of  the  claw. 

Starting  with  fully  charged  batteries,  both  the  ACV  and  TCV  were  able  to 
perform  various  mission  tasks  for  two  hours  without  changing  batteries 

The  ACV  marginally  passed  the  autonomous  ability  test.  The  system  was  able  to 
travel  out  a  distance,  turn  around  and  return  to  nearly  the  same  spot.  However,  the  system 
routinely  was  a  few  inches  off  from  the  start  point.  This  is  likely  due  to  the  trimming  of 
the  robot.  Fine  tuning  the  trimming  to  the  floor  surface  improved  the  ACV’s  ability  to 
return  to  the  original  starting  point. 

When  performing  the  vial  location  test  for  the  ACV  the  system  was  not  able  to 
find  the  vial.  The  test  team  tried  many  different  methods  to  try  and  determine  the 
problem.  The  test  team  finally  detennined  that  the  ultrasonic  sensor  had  malfunctioned 
and  was  not  providing  the  system  with  proper  readings.  A  properly  functioning  sensor 
was  added  to  the  system,  which  corrected  the  issue.  The  problem  was  not  observed  again 
during  testing. 


96 


3.  Standard  Nominal  Clearing  Test 

a.  Objective 

•  The  objective  the  standard  nominal  clearing  test  (SNCT)  is  to  give  a  base  line 
test  that  was  used  to  compare  the  perfonnance  and  reliability  of  the 
TECHMAN  ACV  and  TCV.  The  SNCT  is  based  off  of  a  representative 
mission 

b.  Criteria  and  Data  Analysis 

•  The  results  of  the  SNCT  were  used  to  determine  the  performance,  reliability, 
and  safety  of  the  TECHMAN  ACV  and  TCV.  The  SNCT  provided  input  to 
evaluation  of: 

•  KPP  3-4 

•  KSA  1-3 

•  KSA  5 

•  KSA  6-13 

•  APA  3-5 

c.  Test  Procedures  and  Data  Required 

Figure  42  shows  the  16  square  foot  test  area  for  the  SNCT.  The  vials  were  placed 
in  a  specific  pattern.  The  TECHMAN  ACV  and  TCV  ran  through  the  SNCT  four  times 
each.  The  systems  proceed  from  the  corral  area  to  find  and  retrieve  the  vials  and  return 
the  vials  to  the  corral  area.  Time  to  clear  the  area  was  recorded,  number  of  vials  returned, 
system  identification  of  the  vials  (correct  or  incorrect),  number  of  battery  swaps  required, 
and  any  system  failures  or  anomalies. 
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Figure  42.  SNCT  Vial  Configuration 


The  following  data  was  recorded: 

•  overall  time  to  clear  area 

•  time  per  vial 

•  average  time  per  vial 

•  number  of  vials  returned 

•  number  of  battery  swaps 

•  system  failures 

•  battery  swaps 

•  any  additional  maintenance 

•  photographs 

d.  Standard  Nominal  Clearing  Test  Results 

Figure  43  shows  a  photograph  of  the  standard  mission  test  layout.  Five  vials  are 
arranged  in  a  very  specific  order. 
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Figure  43.  SNCT  Layout  Photograph 


•  TCV  Standard  Mission  Results: 

The  TCV  perfonned  the  standard  mission  five  times.  Each  mission  had  a  success 
rate  of  100%  with  no  vials  missed  or  knocked  over.  No  faults  resulting  in  an  essential 
function  failure  (EFF)  or  mission  abort  were  experienced.  That  average  time  to  retrieve  a 
single  vial  was  29  seconds  and  the  average  time  to  complete  the  entire  clearing  mission 
was  two  minutes  and  26  seconds.  No  battery  changes  were  required  during  testing.  No 
maintenance  was  required  during  testing.  A  learning  curve  was  observed  and  the  clearing 
times  were  slightly  quicker  after  the  first  few  runs. 

The  TCV  did  not  have  the  capability  to  distinguish  the  vials  during  testing 
therefore  no  data  recorded  relating  to  identification  of  vials. 

•  ACV  Standard  Mission  Results: 

The  ACV  perfonned  the  standard  mission  five  times.  The  average  mission 
success  rate  was  96%  with  the  ACV  missing  one  vial.  The  ACV  appeared  to  see  the  vial 
that  was  missed  but  did  not  properly  line  up  with  the  vial  causing  it  to  miss.  No  vials 
were  knocked  over  during  testing.  The  vial  that  was  missed  was  later  retrieved  meaning 
eventually  the  ACV  retrieved  all  of  the  vials.  Two  faults  resulting  in  an  EFFs  were 

experienced.  The  system  required  a  restart  to  correct  the  fault. 
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The  average  time  to  retrieve  a  single  vial  was  49  seconds  and  the  average  time  to 
complete  the  entire  clearing  mission  was  nine  minutes.  No  battery  changes  were  required 
during  testing.  No  maintenance  was  required  during  testing. 

The  ACV  did  not  have  the  capability  to  distinguish  the  vials  during  testing 
therefore  no  data  recorded  relating  to  identification  of  vials. 

4.  Non-Standard  Clearing  Test 

a.  Objective 

•  The  objective  the  non-standard  clearing  test  (NSCT)  is  to  give  a  Non-Standard 
mission  representative  test  to  verify  the  SNCT  did  not  provide  any  bias 
between  the  TECHMAN  ACV  and  TCV. 

b.  Criteria  and  Data  Analysis 

•  The  results  of  the  NSCT  were  used  to  determine  the  performance,  reliability, 
and  safety  of  the  TECHMAN  ACV  and  TCV  and  provide  a  comparison 
against  the  SNCT  to  ensure  bias  was  not  introduced.  The  NSCT  provided 
input  to  evaluation  of: 

•  KSA  1-3 

•  KSA  5 

•  KSA  5 

•  KSA  6-13 

•  APA  3-5 

c.  Test  Procedures  and  Data  Required 

Figure  44  shows  the  16  square  foot  test  area  for  the  NSCT.  The  vials  were  placed 
in  a  random  pattern.  The  TECHMAN  ACV  and  TCV  were  run  through  the  SNCT  one 
time  each.  Each  system  started  in  the  corral  area  then  proceeded  to  find  and  retrieve  the 
vials  and  return  the  vials  to  the  corral  area.  Time  to  clear  the  area  was  recorded  along 
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with  the  number  of  vials  returned,  number  of  battery  swaps  required,  and  any  system 
failures  or  anomalies.  The  NSCT  results  were  compared  against  the  SNCT  results. 


4  ft 


Figure  44.  NSCT  Vial  Configuration 


The  following  data  were  recorded: 

•  overall  time  to  clear  area 

•  time  per  vial 

•  average  time  per  vial 

•  number  of  vials  returned 

•  correct  or  incorrect  identification  of  vials 

•  number  of  battery  swaps 

•  system  failures 

•  battery  swaps 

•  any  additional  maintenance 

•  photographs 
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d.  Non-Standard  Clearing  Test  Results 

Figure  45  is  a  photograph  of  the  standard  mission  test  layout.  Five  vials  are 
arranged  in  a  specific  order. 


Figure  45.  NSCT  Layout  Photograph 

•  TCV  Non-Standard  Mission  Results: 

The  TCV  perfonned  the  Non-Standard  clearing  test  five  times.  Each  mission  had 
a  success  rate  of  100%  with  no  vials  missed  or  knocked  over.  No  faults  resulting  in  an 
EFF  or  mission  abort  were  experienced.  That  average  time  to  retrieve  a  single  vial  was  3 1 
seconds  and  the  average  time  to  complete  the  entire  clearing  mission  was  two  minutes 
and  35  seconds.  No  battery  changes  were  required  during  testing.  No  maintenance  was 
required  during  testing. 

The  TCV  did  not  have  the  capability  to  distinguish  the  vials  during  testing 
therefore  no  data  recorded  relating  to  identification  of  vials. 
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•  ACV  Non-Standard  Clearing  Test  Mission  Results: 

The  ACV  perfonned  the  Non-Standard  clearing  test  two  times.  The  average 
mission  success  rate  was  59%.  When  there  were  two  vials  that  did  not  have  much 
separation  in  the  ACV’s  sightline,  the  ACV  appeared  to  see  them  as  one.  The  ACV 
would  then  proceed  to  the  center  of  the  two  vials  causing  it  to  miss  both  vials.  Because  of 
this,  the  ACV  required  many  runs  to  clear  the  entire  test  area.  The  operator  had  the  ACV 
perform  its  search  from  different  areas,  which  helped  the  problem  but  did  not  eliminate 
the  issue  entirely.  Five  faults  resulting  in  an  EFF  were  experienced.  The  system  required 
a  restart  to  correct  the  faults. 

The  average  time  to  retrieve  a  single  vial  was  47  seconds  and  the  average  time  to 
complete  the  entire  clearing  mission  was  14  minutes  30  seconds.  No  battery  changes 
were  required  during  testing.  No  maintenance  was  required  during  testing. 

The  ACV  did  not  have  the  capability  to  distinguish  the  vials  during  testing 
therefore  no  data  recorded  relating  to  identification  of  vials. 

C.  EVALUATION 

1.  Requirements  And  Mission  Evaluation 

The  ACV  and  TCV  were  evaluated  against  system  requirements  and  against  the 
DRM.  Table  19  is  the  rating  criteria  for  meeting  the  requirements  and  effectiveness, 
suitability,  and  survivability  (ESS).  Table  20  is  the  rating  criteria  for  operational  impact 
against  the  DRM.  The  criteria  described  in  the  tables  were  used  to  assess  the  robots 
ability  to  meet  the  KPP  and  attributes. 
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Table  19.  ESS  Assessment  Four-Color  Rating  Scheme  and  Definitions  (after  Department 

of  the  Army  2011) 


Rating 

Color 

Symbol 

Program  Requirement  Rating  Definition 

Met 

Green 

G 

A  green  rating  indicates  that  the  system  satisfied  the 
threshold  requirement  as  stated  in  the  requirement  document 
and/or  applicable  regulatory  document  with  justified 
confidence  according  to  the  T&E  strategy. 

Partially 

Met 

Yellow 

Y 

A  yellow  rating  indicates  that  the  system: 

•  Satisfied  part  of  the  requirement. 

•  Met  the  threshold  requirement  as  stated  in  the 
requirement  document  and/or  applicable  regulatory 
document  with  low  confidence  according  to  the 

T&E  strategy.  May  include  recommendations  for  a 
path  forward  to  address  deficiencies  to  become 
operationally  effective  or  sui . 

•  Required  a  workaround  in  order  to  satisfy  the 
requirement. 

Not  Met 

Red 

G 

A  red  rating  indicates  that  the  system: 

•  Did  not  meet  the  minimum  threshold  requirement 
as  stated  in  the  requirement  document  and/or 
applicable  regulatory  document. 

•  May  include  recommendations  for  a  path  forward  to 
address  deficiencies  to  become  operationally 
effective  or  suitable. 

Unknown 

Grey 

• 

A  grey  rating  indicates  that  the  system  performance  for  the 
particular  requirement  is  not  known  and  cannot  be 
determined  from  the  information  and  data  available. 

Table  20.  Operational  Impact  Rating  and  Color  Scheme  (after  Department  of  the  Army 
_ 2011) _ 


Rating 

Symbol 

Operational  Impact  Rating  Definition 

Similar  or 
Enhanced 
Capability 

G 

The  system  evaluation  finding  indicates  that  the  operational 
capability  is  similar  to  current  capabilities,  provides  an  improved 
capability,  or  provides  a  new  capability,  relative  to  the 
requirement. 

Reduced 

Capability 

A 

The  system  evaluation  finding  indicates  that  the  system  may  result 
in  decreased  mission  capability,  relative  to  the  requirement. 

Significantly 

Degraded 

Capability 

A 

The  system  evaluation  finding  indicates  that  the  system  may  have 
significant,  negative  impact  on  mission  capability,  relative  to  the 
requirement. 

Unknown 

/0\ 

The  system  impact  on  mission  operations  is  not  known  and  cannot 
be  determined  from  the  information  and  data  available. 
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a.  A  CV  Evaluation 

Table  21  covers  the  evaluation  ratings  of  the  ACV  in  comparison  to  the  KPPs, 
KSAs,  and  Attributes  along  with  the  operational  impact.  The  table  also  contains 
recommendations  for  the  ACV.  The  overall  evaluation  of  the  ACV  is  the  system  effective 
in  completing  its  mission.  However,  there  are  many  limitations  causing  it  to  complete  its 
mission  in  a  degraded  manner  and  requiring  more  operator  input. 


Table  21.  ACV  Assessment  Requirements,  Ratings,  and  Recommendations 


Operational 

Task 

Requirement 
(source):  description 

Requirement 

Rating 

Operational 

Impact 

Recommendation 
and/or  Materiel 
Release  Condition 

Pass  and 
receive 
mission 
information 

KSA1:  The  robot  shall 
notify  the  operator  of 
system  malfunctions 

G 

G 

Have  discriptor  of 
the  errors  to  help 
with  problem 
dignosis 

KSA2:  The  robot 
shall  store  a  mission 
log  file  for  retrieval  by 
the  operator 

O 

The  robot  did 

not  store  a 
mission  log 

Users  would  not 
be  able  to 
retrive  mission 
data 

Future  updates  of  the 
robot  shall  keep  a  log 

file 

KSA3:  When 
returning  a  vial  to  the 
corral,  the  robot  shall 
play  a  distinct  sound 
for  a  “hazardous  vial” 
and  a  different  sound 
for  an  inert  vial 

• 

The  robot  did 
not  determine 
vial  type  or 
play  sounds 

Users  would  not 
know  the  vial 
type 

Future  updates  of  the 
robat  should  notify 
the  operator  of 
mission  outcome 

Operate  in 

intended 

environment 

KPP1:  The  robot  shall 
run  for  2  hours 
without  swapping 
batteries 

G 

None 

KPP2:  The  system 
shall  be  transportable 
in  Two  containers, 
with  the  weight  of 
each  container  not  to 
exceed  35  lbs 

G 

System  is  easily 
damaged  during 
transport  and 
parts  can  be  lost 

Extra  caution  should 
be  used  during 
transport 

KSA4:  The  robot  shall 
be  powered  by  6  AA 
batteries  or 
rechargeable 
equivalent 

G 

G 

None 
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Operational 

Task 

Requirement 
(source):  description 

Requirement 

Rating 

Operational 

Impact 

Recommendation 
and/or  Materiel 
Release  Condition 

KSA5:  The  system 
shall  operate  in  a 
manner  safe  to  its 
operators 

G 

G 

None 

APA  1 :  Batteries  shall 
be  replaceable  within 
two  minutes 

G 

Changing 
batteries 
requires  some 
disassembly  of 
the  robot 

User  should  use 
caution  to  ensure 
parts  are  not  lost  or 
damaged  during 
battery  changes 

APA  2:  The  system 
shall  comply  with  the 
FCC’s  requirements 
for  a  Class  D  device 

G 

jL 

None 

APA  3 :  The  system 
shall  be  operated  by 
not  more  than  one 
servicemember 

G 

G 

None 

Propel  itself 
under  its  own 
power, 
including 
while 

carrying  vials 

KSA6:  The  robot  shall 
traverse  terrain  of 
smooth  concrete  or 
blacktop  surfaces 

G 

G 

None 

KS A7 :  The  robot  shall 
be  able  to  change  its 
heading  to  any  360 
degree  orientation 

G 

Improper 
triming  causes 
the  robot  to  be 
out  of  posit  ion 

Allow  for  robot  to 
automatically  “trim” 
to  account  for  the 
different  type  of 
surfaces  encountered 

Clear  a  given 
area  of 
radiological 
threats 

KPP3 :  The  robot  shall 
clear  a  rectangular 
area  (the  “target  area”) 
of  a  defined  size 

G 

G 

None 

KPP4:  The  robot  shall 
secure  all  vials  and 
return  them  to  the 
corral  for  disposal  by 
trained  personnel  and 
a  separate  system  with 
a  0.9  probability 

G 

The  system 
had  an  0.59 
probability  of 
securing  vials 

Significat 
mission  delays 
will  occur  with 
possible  missed 
vials. 

Future  updates  of  the 
robot  should  increase 
probability  of 
retrieving  a  vial. 

KSA8:  The  robot  shall 
distinguish  a 
“hazardous”  colored 
vial  from  vials  of  other 
colors  with  a  90% 
probability  of 
distinction 

o 

The  robot  did 
not  determine 
vial  type 

Users  would  not 
know  the  vial 
type 

Future  updates  of  the 
robat  should  obtain 
this  capability 
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Operational  Requirement  Requirement  Operational  Recommendation 

Task  (source):  description  Rating  Impact  and/or  Materiel 

Release  Condition 


KSA9:  The  system 
shall  detect  vials  under 
fluorescent  lighting 
conditions 

G 

G 

None 

KSA12:  The  system 
shall  have  the  0.75 
probability  of 
completing  a  2 
mission  hours  without 
an  essential  function 
failure. 

Y 

Several  EFFs 

were 

experienced 
which  required 
a  system 
restart  to 

correct 

EFFs  would 
cause  mission 
delays  and 
possibily  place 
servicemembers 
in  danger 

Increase  reliability 

KSA13:  The  system 
shall  have  a  0.95 
probability  of 
completing  2  mission 
hours  without  a  system 
abort 

G 

G 

None 

APA4:  The  system 
shall  not  exceed  0.04 
MMH/OH  ratio 

G 

Unscheduled 
maintenance 
time  was  high 
due  to  the 
number  to 
EFFs 

EFFs  would 
cause  mission 
delays  and 
possibily  place 
servicemembers 
in  danger 

EFFs  need  to  be 
reduced  to  improve 
the  amount  of 
unscheduled 
maintenance. 

APA5:  The  system 
shall  pass  the  Standard 
Mission  and  Non- 
Standard  Clearing  Test 
Pattern  in  15  minutes 

Y 

Average 
mission  time 
met  the  req  but 
some  missions 
required  more 
time 

jL 

Mission  delays 
could  be 
experienced 

Improving  detecting 
and  retrieving 
capability  will 
improve  the  mission 
time 

As  can  be  seen  in  the  evaluation  table,  the  ACV  did  not  meet  some  requirements 
set  forth  in  the  CDD.  The  robot  did  not  store  a  log  file  and  did  not  distinguish  vials. 
Because  it  did  not  distinguish  vials  it  also  did  not  notify  the  operator  of  the  type  of  vial 
found.  While  this  did  not  have  a  large  effect  on  mission  completion,  it  does  require  more 
work  by  the  cleanup  team  and  could  possibly  place  them  in  a  dangerous  situation.  Design 
improvements  should  be  made  to  satisfy  this  capability  if  the  program  continues  past  MS 
B. 
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The  next  issue  found  during  testing  which  would  have  a  large  operational  impact 
is  the  low  probability  of  detecting  vials,  especially  vials  that  are  close  together.  The  robot 
eventually  was  able  to  clear  all  the  vials  but  mission  time  significantly  increased  due  to 
the  extra  time  taken  to  travel  out  and  scan  again  for  vials.  If  the  system  is  operating  in  an 
area  without  line  of  sight,  the  operator  may  not  have  much  confidence  that  the  system  has 
collected  all  the  vials.  This  could  expose  users  to  hazards  in  an  area  they  thought  was 
clear.  Later  updates  of  the  robot  may  increase  search  accuracy  by  better  sensors  or 
different  search  patterns. 

The  ACV  experienced  a  number  of  EFFs  during  testing.  All  of  the  EFF  were 
experienced  while  starting  the  system  and  were  corrected  by  a  full  system  restart. 
However,  the  EFFs  caused  delays  leading  to  longer  mission  time  and  more  operator 
interaction. 

b.  TCV Evaluation 

Table  22  covers  the  evaluation  ratings  of  the  TCV  in  comparison  to  the  KPPs, 
KSAs,  and  Attributes  along  with  the  operational  impact.  The  table  also  contains 
recommendations  for  the  TCV.  The  overall  evaluation  of  the  TCV  is  the  system  effective 
in  completing  its  mission.  However,  there  are  some  limitations  causing  it  to  complete  its 
mission  in  a  degraded  manner  and  requiring  more  input  from  the  operator.  The 
limitations  are  the  same  as  the  ACV  with  regards  to  keeping  a  log  file  and  distinguishing 
vials. 
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Table  22.  TCV  Assessment  Requirements,  Ratings,  and  Recommendations 


Operational 

Task 

Requirement 
(source):  description 

Requirement 

Rating 

Operational 

Impact 

Recommendation 
and/or  Materiel 
Release  Condition 

Pass  and 
receive 
mission 
information 

KSA1:  The  robot  shall 
notify  the  operator  of 
system  malfunctions 

G 

G 

Have  discriptor  of 
the  errors  to  help 
with  problem 
dignosis 

KSA2:  The  robot 
shall  store  a  mission 
log  file  for  retrieval  by 
the  operator 

o 

The  robot  did 

not  store  a 
mission  log 

Users  would  not 
be  able  to 
retrive  mission 
data 

Future  updates  of  the 
robot  shall  keep  a  log 

file 

KSA3:  When 
returning  a  vial  to  the 
corral,  the  robot  shall 
play  a  distinct  sound 
for  a  “hazardous  vial” 
and  a  different  sound 
for  an  inert  vial 

• 

The  robot  did 
not  determine 
vial  type  or 
play  sounds 

▲ 

Users  would  not 
know  the  vial 
type 

Future  updates  of  the 
robat  should  notify 
the  operator  of 
mission  outcome 

Operate  in 

intended 

environment 

KPP 1 :  The  robot  shall 
run  for  2  hours 
without  swapping 
batteries 

G 

G 

None 

KPP2:  The  system 
shall  be  transportable 
in  Two  containers, 
with  the  weight  of 
each  container  not  to 
exceed  35  lbs 

G 

System  is  easily 
damaged  during 
transport  and 
parts  can  be  lost 

Extra  caution  should 
be  used  during 
transport 

KSA4:  The  robot  shall 
be  powered  by  6  AA 
batteries  or 
rechargeable 
equivalent 

G 

jL 

None 

KSA5:  The  system 
shall  operate  in  a 
manner  safe  to  its 
operators 

G 

G 

None 

APA  1:  Batteries  shall 
be  replaceable  within 
two  minutes 

G 

Changing 
batteries 
requires  some 
disassembly  of 
the  robot 

User  should  use 
caution  to  ensure 
parts  are  not  lost  or 
damaged  during 
battery  changes 

APA  2:  The  system 
shall  comply  with  the 
FCC’s  requirements 
for  a  Class  D  device 

G 

G 

None 
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Operational 

Task 

Requirement 
(source):  description 

Requirement 

Rating 

Operational 

Impact 

Recommendation 
and/or  Materiel 
Release  Condition 

APA  3 :  The  system 
shall  be  operated  by 
not  more  than  one 
servicemember 

G 

G 

None 

Propel  itself 
under  its  own 
power, 
including 
while 

carrying  vials 

KSA6:  The  robot  shall 
traverse  terrain  of 
smooth  concrete  or 
blacktop  surfaces 

G 

A. 

None 

KSA7:  The  robot  shall 
be  able  to  change  its 
heading  to  any  360 
degree  orientation 

G 

A 

None 

Clear  a  given 
area  of 
radiological 
threats 

KPP3:  The  robot  shall 
clear  a  rectangular 
area  (the  “target  area”) 
of  a  defined  size 

G 

G 

None 

KPP4:  The  robot  shall 
secure  all  vials  and 
return  them  to  the 
corral  for  disposal  by 
trained  personnel  and 
a  separate  system  with 
a  0.9  probability 

G 

A 

None 

KSA8:  The  robot  shall 
distinguish  a 
“hazardous”  colored 
vial  from  vials  of  other 
colors  with  a  90% 
probability  of 
distinction 

G 

The  robot  did 
not  determine 
vial  type 

A 

Users  would  not 
know  the  vial 
type 

Future  updates  of  the 
robat  should  obtain 
this  capability 

KSA12:  The  system 
shall  have  the  0.75 
probability  of 
completing  a  2 
mission  hours  without 
an  essential  function 
failure. 

G 

G 

None 

KSA13:  The  system 
shall  have  a  0.95 
probability  of 
completing  2  mission 
hours  without  a  system 
abort 

G 

G 

None 

APA4:  The  system 
shall  not  exceed  0.04 
MMH/OH  ratio 

G 

A 

None 
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Operational 

Task 

Requirement 
(source):  description 

Requirement 

Rating 

Operational 

Impact 

Recommendation 
and/or  Materiel 
Release  Condition 

APA5:  The  system 
shall  pass  the  Standard 
Mission  and  Non- 
Standard  Clearing  Test 
Pattern  in  15  minutes 

G 

G 

None 

2.  ACV  And  TCV  Comparison 

One  of  the  research  questions  involved  comparing  impacts  to  the  mission  for  the 
ACV  and  TCV.  The  ACV  and  TCV  perform  the  same  mission;  however,  the  service 
members  use  the  systems  in  a  different  manner.  As  covered  earlier  in  the  report,  the 
operator  controls  the  TCV  where  the  ACV  clears  the  area  on  its  own. 

Table  23  shows  the  success  rate,  average  time  to  clear  an  individual  vial,  and  the 
overall  average  mission  time.  The  result  shows  that  the  TCV  is  more  accurate  at  clearing 
the  vials  and  was  able  to  complete  the  mission  in  significantly  less  time.  This  is  the  main 
advantage  of  the  TCV.  If  one  operator  is  able  to  focus  her  time  entirely  on  one  mission 
area,  then  the  TCV  should  be  used. 


Table  23.  Clearing  Test  Results 


Parameter 

ACV 

ACV  (Non- 

TCV 

TCV  (Non- 

(Standard) 

Standard) 

(Standard) 

Standard) 

Success  Rate  Standard  % 

96 

59 

100 

100 

Ave  Time  Per  Vial  (seconds) 

49 

47 

29 

31 

Ave  Mission  Time  (seconds) 

540 

870 

146 

155 

There  are  some  disadvantages  to  using  the  TCV  for  the  clearing  mission  however. 
The  first  and  main  disadvantage  is  it  requires  the  operator’s  full  attention  throughout  the 
clearing  mission.  This  means  that  one  operator  can  only  operate  one  TCV  at  time.  A 
second  disadvantage  of  this  system  is  it  requires  the  operator  to  have  a  line  of  sight  of  the 
clearing  area. 
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The  main  advantage  of  the  ACV  on  the  other  hand  is  the  operator  can  start  the 
system  on  the  clearing  mission  and  then  move  his  attention  to  other  tasks.  The  operator 
also  does  not  need  line  of  sight  of  the  clearing  area.  This  allows  one  operator  the  ability 
to  run  multiple  ACV  systems  at  a  time  which  affords  him  the  ability  to  clear  more  area  in 
less  overall  mission  time. 

The  current  ACV  has  some  disadvantages  due  to  its  low  probability  of  detection 
and  must  be  restarted  after  each  clearing  run  requiring  more  operator  time  and  input. 
Another  disadvantage  of  the  ACV  is  more  training  is  required  for  setting  the  system  up 
for  the  clearing  mission.  Operators  must  input  the  clearing  parameters  of  the  clearing  area 
before  the  mission  is  started. 

Following  the  JCIDS/DAS  process,  if  the  program  proceeded  beyond  MS  B  the 
systems  would  continue  to  be  refined  and  some  of  the  disadvantages  could  be  corrected 
making  the  ACV  more  effective  and  requiring  less  operator  input. 

In  the  current  state  of  the  TECHMAN  systems  the  TCV  is  likely  the  better  option 
for  completing  the  mission.  However,  if  improvements  were  made  to  address  accuracy 
and  reduce  mission  time,  the  ACV  it  would  become  the  better  option. 
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VII.  SYSTEM  SU PPORT ABILITY 


A.  LIFE-CYCLE  COST 


Life-cycle  cost  estimations  are  based  on  the  notional  life-cycle  cost  estimates 
shown  in  Figure  46.  The  percentages  are  approximations  and  provide  a  basis  for 
estimation  of  the  cost  over  each  life-cycle. 


DEMONSTRATION  PHASE 


CONCEPT  REFINEMENT  AND 
TECHNOLOGY  DEVELOPMENT 
PHASE 


DISPOSAL  PHASE 


PRODUCTION  AND  DEPLOYMENT  PHASE 


SUSTAINMENT  PHASE 


Program  Life-Cycle  (Illustrative) 


Figure  46.  Notional  Profile  of  Annual  Program  Expenditures  (after  Defense 
Acquisition  Guidebook,  Section  3.1.2) 
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1. 


Research  And  Development  Cost 


The  leJOS  programming  environment  is  free  to  use;  however,  there  was  some 
time  involved  in  our  team  members  becoming  familiar  with  the  Java  language,  and  the 
leJOS-specific  libraries  and  tools.  Software  development  costs  include  these  hours  spent 
learning  the  tools  and  the  hours  spent  writing  the  code.  The  ACV  software  package  took 
four  times  the  amount  of  time  in  preparing  and  setting  up  the  leJOS  environment  than  the 
TCV  software  package.  In  time  spent  writing  the  code  the  ACV  software  package 
required  three  times  the  amount  of  time  than  the  TCV  software  package.  Table  24 
summarizes  the  hours  spent  in  learning  leJOS,  setting  up  the  environment,  and  writing 
the  code  for  both  vehicles. 


Table  24.  Software  Development  Labor  Hours 


Platform 

Hrs.  learning  leJOS/setting 
up  environment 

Hrs.  Writing  Code 

Total  Hrs. 

ACV 

20 

60 

80 

TCV 

5 

20 

25 

The  hours  spent  in  designing  the  robot  are  included  in  the  Mechanical 
Engineering  hours.  The  two  designs  use  the  same  hardware  configuration  and  the 
hardware  design  costs  are  shared  between  the  two  vehicles.  The  final  design  is 
documented  with  a  parts  list,  model  and  assembly  instructions  using  the  LEGO  Digital 
Designer  (LDD). 

The  system  cost  includes  the  cost  of  piece  parts,  assembly,  training,  operators,  and 
support  equipment.  Piece  parts  and  assembly  costs  are  the  same  for  both  the  TCV  and 
ACV.  Figure  47  lists  the  itemized  cost  of  the  piece  parts.  The  parts  list  in  Figure  47  was 
exported  from  the  LDD  model  while  the  prices  of  the  parts  was  obtained  from 
LEGO.com  or  equivalent  vendor  sites  online.  The  bill  of  materials  (BOM)  to  reproduce 
an  ACV  or  TCV  unit  is  $376.66.  The  TCV  requires  a  laptop  to  run  which  is  an  additional 
hardware  cost  of  approximately  $400. 
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Hourly  rates  obtained  from  the  Bureau  of  Labor  Statistics  National  Occupational 
Employment  Statistics  are  used  in  estimating  the  design  and  development  costs.  During 
the  project  the  team  members  perfonned  functions  similar  to  a  PM,  systems  engineer 
(SE),  mechanical  engineer  (ME),  software  developer  (SD),  and  a  technical  writer  (TW). 
Overhead  costs  are  factored  in  at  a  conservative  30%  of  the  labor  costs.  Table  25  and 
Table  26  summarize  the  estimated  labor  costs  for  the  TCV  and  ACV,  respectively. 


Table  25.  Current  TOY  Wages  and  Overhead  Costs 


Labor  Act 

Hourly  Rate 

Total  Hours 

Wages 

Overhead 

PM/SE 

$55.81 

135 

$7,534.35 

$2,260.31 

ME 

$41.31 

270 

$11,153.70 

$3,346.11 

SD 

$46.28 

25 

$1,157.00 

$347.10 

TW 

$33.80 

190 

$6,422.00 

$1,926.60 

Total 

$26,267.05 

$7,880.12 

Table  26.  Current  ACV  Wages  and  Overhead  Costs 


Labor  Act 

Hourly  Rate 

Total  Hours 

Wages 

Overhead 

PM/SE 

$55.81 

135 

$7,534.35 

$2,260.31 

ME 

$41.31 

270 

$11,153.70 

$3,346.11 

SD 

$46.28 

80 

$3,702.40 

$1,110.72 

TW 

$33.80 

190 

$6,422.00 

$1,926.60 

Total 

$28,812.45 

$8,643.74 

The  project  is  approximately  50%  of  the  way  through  the  research  and 
development  (R&D).  The  projected  total  for  completion  of  the  R&D  life-cycle  is 
summarized  in  Table  27. 


Table  27.  R&D  Life-Cycle  Phase  Estimated  Cost 


Vehicle 

Wages 

Overhead 

Hardware 

Current 

Total 

Projected  Total 

TCV 

$26,267.05 

$7,880.12 

$768.66 

$34,914.83 

$69,829.65 

ACV 

$28,812.45 

$8,643.74 

$367.66 

$37,823.85 

$75,647.69 
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2. 


Investment  Cost 


Investment  cost  is  estimated  to  be  30%  of  the  life-cycle  cost.  Projections  from  the 
R&D  estimate  provide  a  basis  for  the  estimation  of  the  investment  life-cycle  cost.  Table 
28  summarizes  the  estimate  for  the  life-cycle  cost. 

3.  Operating  and  Support  Cost 

Operating  and  Support  (O&S)  cost  is  estimated  to  be  56%  of  the  life-cycle  cost. 
Projections  from  the  R&D  estimate  provide  a  basis  for  the  estimation  of  the  O&S  life- 
cycle  cost.  Table  28  summarizes  the  estimate  for  the  life-cycle  cost. 

4.  Disposal  Cost 

Disposal  cost  is  estimated  to  be  4%  of  the  life-cycle  cost.  Projections  from  the 
R&D  estimate  provide  a  basis  for  the  estimation  of  the  disposal  life-cycle  cost.  Table  28 
summarizes  the  estimate  for  the  life-cycle  cost. 

5.  Total  Life-Cycle  Cost 

The  life-cycle  cost  includes  the  costs  over  each  of  the  life-cycle  phases.  Table  28 
summarizes  these  costs  of  each  phase  and  the  life -cycle  cost  for  each  vehicle.  From  the 
extrapolations  based  on  current  cost  accruals  the  ACV’s  life-cycle  cost  is  estimated  to  be 
8.3%  greater  than  the  life-cycle  cost  of  the  TCV. 


Table  28.  Summary  of  Life-cycle  Costs  for  TCV  and  ACV 


Life-cycle  Phase 

TCV 

ACV 

R&D 

$69,829.65 

$75,647.69 

Investment 

$209,488.95 

$226,943.07 

O&S 

$391,046.04 

$423,627.06 

Disposal 

$27,931.86 

$30,259.08 

LCC 

$698,296.50 

$756,476.90 
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B.  TRAINING 

1.  Common  Training 

Most  of  the  common  training  would  not  change  between  the  ACV  and  TCV, 
simply  because  of  the  device’s  mission.  The  clearance  vehicle  only  brings  hazardous 
vials  from  a  dangerous  location  to  a  less  dangerous  location,  where  the  operator  must 
dispose  them.  We  expect  most  of  the  operator  training  will  consist  of  how  to  properly 
dispose  of  a  hazardous  vial  and  a  substantially  smaller  amount  of  the  training  will  consist 
of  training  on  the  clearance  vehicle. 

For  the  portion  of  the  operator  training  focused  on  clearance  vehicles,  the  largest 
portion  would  probably  cover  the  operator  level  maintenance  tasks  covered  in  the 
operator’s  manual  portion  of  the  Technical  Manual.  Due  to  the  common  system  design 
for  the  Clearance  Vehicles,  the  operator’s  maintenance  of  the  CVs  themselves  will  likely 
be  the  same.  Tasks  include  replacing  the  batteries,  replacing  the  treads,  and  loading 
software  updates  onto  the  system. 

2.  TCV  Training 

The  TCV’s  training  is  straight  forward  as  the  system  is  fairly  simple.  The 
operators  will  need  to  know  how  to  turn  on  the  field  laptop,  turn  on  the  robot,  and 
connect  the  two.  Once  connected  the  operator  interface  is  straightforward.  The  OCU  has 
buttons  for  forward,  reverse,  steer  left,  steer  right,  speed  control,  lift  arm  up,  and  lift  arm 
down. 

The  TCV  does  have  a  learning  curve  for  the  operator  that  should  be  taken  into 
consideration.  It  will  take  a  new  operator  some  time  to  learn  the  controls  and  how  the 
robot  responds  to  input.  Also,  depending  on  the  experience  the  operator  has  operating 
teleopera  ted  system  additional  time  may  be  need  to  learn  to  drive  the  system. 
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3. 


ACV  Training 


The  ACV  specific  tasks  that  operators  need  to  be  trained  on  are  largely 
diagnostics,  which  are  useful  for  the  level  maintainers.  Operators  will  need  to  know  how 
to  properly  conduct  and  record  the  results  of  the  four  calibration  missions  so  they  can 
have  their  system  recalibrated.  Recalibrating  the  system  is  not  an  operator  level  task. 

The  operation  of  the  system  is  fairly  straightforward.  The  ACV  requires  the 
operator  to  cordon  off  the  area  and  then  press  a  single  button.  Because  the  ACV  is 
autonomous,  no  further  operator  intervention  is  necessary  until  the  ACV  returns.  The 
actual  operation  of  the  ACV  is  a  small  part  of  the  operator’s  overall  job,  and  the  ACV 
Operator’s  training  should  reflect  that. 

C.  MAINTENANCE 

1.  Evaluation  of  Maintainability 

No  reliability  or  maintainability  requirements  were  tested  during  the  test  and 
evaluation  portion  of  the  project.  The  TECHMAN  systems  were  not  utilized  enough  to 
require  maintenance  tasks.  However,  the  test  team  gained  some  insights  during  system 
development  and  testing  of  the  systems. 

Testing  found  that  the  ACV  can  take  around  10  minutes  longer  per  mission  than 
the  TCV.  Over  the  lifetime  of  the  system,  this  would  lead  to  more  battery  swaps  and 
more  wear  on  the  batteries,  tracks,  and  drive  motors.  If  the  program  were  to  continue  post 
MS  B,  then  the  lifespan  of  the  tracks,  motors,  and  other  parts  would  be  determined. 
Knowing  this  lifespan  along  with  system  reliability  would  allow  for  a  proper 
maintainability  assessment. 

Both  the  ACV  and  TCV  were  tested  with  an  OCU,  which  is  operated  on  a 
standard  issue  laptop.  However,  the  TCV  requires  constant  use  of  the  laptop  to  control 
the  system,  which  means  the  laptop,  will  have  more  use  during  mission.  This  will  lead  to 
more  batteries  needed  to  support  the  mission  and  lead  to  a  shorter  life  span  for  the  laptop. 
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Again,  if  the  program  proceeded  post  MS  B,  then  the  laptop  maintenance  needs  would  be 
found  and  a  determination  would  be  made  on  the  maintenance  needs  for  a  mission. 

2.  Scheduled  Maintenance 

No  special  tools  are  required  to  perfonn  any  maintenance  tasks  for  the 
TECHMAN  systems.  At  this  time,  there  are  no  documented  scheduled  maintenance  tasks. 
Likely  scheduled  maintenance  at  defined  intervals  would  include: 

•  check  the  tracks  for  wear 

•  check  the  drives  wheels  and  road  wheels  for  wear  and  proper  lubrication 

•  check  the  drive  motors  for  wear  and  proper  lubrication 

•  check  the  claw  motor  for  wear  and  proper  lubrication 

•  check  the  claw  pivot  points  for  wear  and  proper  lubrication 

•  check  the  battery  compartment  for  corrosion  and  proper  fit  of  batteries 

•  clean  sensors 

•  software  health  check 

D.  TRANSPORTABILITY 

No  transportability  testing  was  complete  due  to  being  early  in  the  JCIDS  process 
and  limitations  of  the  project.  However,  some  observations  were  made  and  a  quick 
analysis  was  completed. 

Figure  48  is  a  transport  case  that  would  meet  the  requirements  to  transport  a 
single  TECHMAN  System.  The  case  is  built  military  specifications  and  cost  around 
$220.  Custom  foam  padding  would  need  to  be  made  to  fit  the  TECHMAN  robot  and 
accessories  would  cost  an  additional  $100  per  case  bringing  the  total  cost  of  the  transport 
cases  to  $320. 
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Figure  48.  Pelican  Transport  Case 

Transporting  the  system  with  this  case  will  meet  the  transportability  requirement 
as  written  in  the  CDD. 

When  transporting  the  TECHMAN  systems  to  the  T&E  site,  the  team  discovered 
the  systems  are  likely  to  fall  apart  during  transport.  While  using  a  custom  fit  case  will 
help  with  that  issue,  it  will  not  eliminate  it.  The  systems  should  be  treated  as  fragile  cargo 
during  transport,  and  someone  at  the  mission  site  time  should  be  dedicated  to  ensuring 
the  system  remained  intact  or  reassembling  any  pieces  that  detached  from  the  system. 
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VIII.  RECOMMENDATIONS  AND  CONCLUSIONS 


A.  TECHNICAL  OUTCOMES 

Within  the  team’s  constraints,  the  TECHMAN  Team  designed,  built,  and 
programmed  two  UGVs:  an  Autonomous  Clearance  Vehicle  and  a  Teleoperated 
Clearance  Vehicle.  Additionally,  the  team  perfonned  an  abbreviated  systems  engineering 
process  in  order  to  ensure  the  TECHMAN  systems  were  built  within  standards  (both 
technical  and  schedule)  and  with  quality  and  life-cycle  concerns  in  mind.  Within  the 
limits  of  the  model,  the  process  was  a  success.  The  team  successfully  delivered  two  well- 
engineered  prototypes  that  could  fulfill  the  needed  capabilities  and  met  most  of  the 
requirements. 

Objectives  that  were  not  achieved  were  outside  the  scope  of  the  model  process. 
For  example,  the  team  had  to  scale  down  the  planned  search  area  from  20  ft  to  4  ft"  due 
to  the  limitations  of  the  sensors.  On  a  real-world  project,  the  team  would  have  had  the 
opportunity  to  substitute  different  sensors  to  achieve  a  greater  scanning  radius,  but  due  to 
the  limits  of  the  provided  kit,  the  team  could  not  use  a  different  model  of  sensor  than 
planned.  Lack  of  sensor  range  also  prevented  the  devices  from  being  able  to  detect  the 
vials’  color. 

A  unique  problem  faced  by  the  ACV  was  location  finding.  Due  to  the  extremely 
limited  capability  of  the  tachometers  in  the  provided  motors  they  could  not  be  used  for 
dead  reckoning.  Additionally,  lack  of  capability  of  the  color  sensor  prevented  the  robot 
from  using  the  blue  tape  perimeter  as  a  landmark  while  navigating.  Use  of  better 
tachometers  or  an  absolute  positioning  solution  (such  as  GPS)  would  have  been  options 
on  a  real  system,  but  were  not  available  to  the  TECHMAN  team  due  to  the  limitations  of 
the  provided  kit. 
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B.  SUMMARY  OF  RESEARCH  QUESTIONS 

1 .  How  well  does  the  JCIDS/DAS  process  support  the  acquisition  and  development 

of  UGVs? 

As  discussed  in  the  first  chapter  of  this  report,  the  majority  of  UGVs  used  by  the 
DOD  are  acquired  using  the  rapid-fielding  process,  which  does  not  follow  a  structured 
process  such  as  JCIDS/DAS.  The  JCIDS/DAS  process  provides  structure  to  ensure 
programs  cover  all  the  needed  life-cycle  items  and  follow  smart  SE.  To  see  if  following 
JCIDS/DAS  was  actually  helpful,  this  project  used  the  essence  of  JCIDS/DAS  to  MS  B. 
This  included  developing  requirements  from  a  user  need,  requirement  analysis,  AOA, 
using  SE  for  system  Design,  T&E,  and  LCC. 

After  completing  this  limited  scope,  the  TECHMAN  team  detennined  that  using 
the  JCIDS/DAS  process  does  a  very  good  job  of  supporting  the  acquisition  and 
development  of  UGVs.  As  found  during  the  initial  research,  many  of  the  current  UGVs 
are  difficult  to  support  and  do  not  meet  performance  needs.  The  JCIDS/DAS  process 
would  reduce  the  number  of  programs  with  problems  like  that  be  fielded.  To  pass 
Milestones,  programs  must  meet  ESS  requirements  and  stay  within  a  budget. 

Another  discovery  was  that  rapid-fielded  programs  have  a  one  step  process  in 
which  the  system  is  designed,  built,  and  fielded.  If  the  TECHMAN  systems  were 
developed  as  a  rapid-fielded  program  they,  the  robots  would  be  fielded  “as  is.”  Thus,  as 
shown  in  this  team’s  evaluation,  the  systems  would  not  meet  the  user  needs.  However, 
the  project  was  in  the  technology  and  development  phase  of  JCIDS/DAS  and  had  just 
reached  MS  B.  The  team  proved  that  the  requirements  were  realistic  and  the  technology 
was  available  to  meet  them,  which  was  one  of  the  main  goals  of  a  pre  MS  B  program. 

The  program  would  continue  on  within  the  JCIDS/DAS  process  in  the  engineering  and 
manufacturing  phase  to  MS  C  and  after  that  the  production  and  deployment  phase. 

During  the  phases  following  MS  B,  improvements  to  the  TECHMAN  systems  would  be 
made  to  ensure  the  systems  meet  the  user  need  before  being  fielded. 

The  downside  to  using  the  JCIDS/DAS  process  was  that  it  takes  much  longer  than 


using  the  rapid-fielding  process.  As  stated  before,  if  the  TECHMAN  systems  were  being 
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completed  as  a  rapid  they  would  be  fielded  now.  Whereas  with  the  JCIDS/DAS  process, 
the  TECHMAN  systems  would  have  more  work  that  must  be  done  before  fielding.  The 
tradeoff  of  the  extra  time  was  a  more  effective,  suitable,  and  supportable  system. 

2.  What  systems  engineering  approaches,  tools,  and  techniques  are  critical  to 
successful  UGV  projects? 

Section  H  in  the  first  chapter,  along  with  the  other  chapters  of  the  report,  covers 
the  SE  methods  used  to  develop  the  TECHMAN  systems.  Most,  if  not  all,  of  the  SE  tools 
used  to  support  the  TECHMAN  systems  could  be  used  on  other  UGVs  within  DOD.  The 
SE  tools  and  JCIDS/DAS  process  are  very  complementary  to  each  other,  which  allowed 
for  a  successful  project.  If  the  project  continued  on  the  SE  tools  and  JCIDS/DAS  process 
would  ensure  the  system  would  meet  the  user  need  from  performance  to  supportability. 

3.  Given  a  set  of  perfonnance  and  suitability  requirements,  how  easily  is  it  to 
accurately  estimate  cost  and  schedule  for  UGV  projects  within  the  JCIDS/DAS 
process? 

Chapter  VII  covers  the  LCC  for  the  TECHMAN  system.  Performance  and 
suitability  requirements  drove  the  hardware  and  software  design  and  the  material  needs  of 
the  system.  The  cost  was  directly  related  to  the  design  time  and  material  needs.  The 
schedule  has  more  flexibility  and  is  tracked  using  EVM  and  project  management. 

If  the  performance  and  suitability  requirements  are  clear  and  well  understood  by 
the  project  time  then  estimating  cost  and  schedule  is  much  easier.  The  TECHMAN 
systems  requirements  were  well  understood  by  the  developers.  Also,  only  minor  changes 
were  made  to  the  requirements  during  the  project,  which  did  not  have  any  cost  or 
schedule  impacts. 

If  the  requirements  were  vague  or  made  drastic  changes  during  the  project,  then 
the  cost  and  schedule  estimates  initially  made  would  likely  become  wrong.  Changes  can 
cause  an  increase  in  cost  and  lengthen  the  schedule. 
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4.  How  much  difference  is  there  in  the  effort  involved  with  developing  teleoperated 
systems  and  the  effort  involved  with  developing  autonomous  systems? 

Chapter  V  that  discusses  the  design  and  Chapter  VII  that  covers  the  LCC  contain 
the  details  of  the  difference  in  effort  involved  with  developing  a  teleoperated  or 
autonomous  system.  To  sum  up  the  findings  the  autonomous  system  required  more  effort. 
The  base  platfonn  of  the  TECHMAN  systems  was  the  same  so  development  time  was 
equal.  However,  software  development  required  and  additional  55  hours  that  resulted  in 
an  additional  estimated  cost  of  $2,545.2  in  labor  (9.7%). 

In  relation  to  UGVs  within  the  DOD,  autonomous  systems  will  require  additional 
effort  then  what  was  seen  with  the  TECHMAN  systems.  The  host  platfonn  would  likely 
not  be  the  same  as  a  teleoperated  one  and  would  have  more  sensors  and  other  subsystems 
to  assist  in  the  autonomous  ability.  Another  aspect  that  could  greatly  increase  effort  with 
autonomous  systems  is  ensuring  the  system  is  safe  to  the  people  around  it.  The 
TECHMAN  ACV  did  not  have  much  of  a  threat  even  if  the  system  malfunctioned  but 
large  autonomous  systems,  especially  ones  with  weapons,  must  operate  in  a  manner  that 
will  not  put  people  around  the  system  in  danger. 

5.  What  are  the  tradeoffs  in  sensors  and  computation  for  autonomous  and 
teleoperated  UGVs? 

As  covered  in  the  answer  for  the  previous  question,  the  ACV  has  greater 
computational  needs  to  retain  the  autonomous  ability.  Additional  code  was  written 
requiring  more  man-hours  to  develop.  The  tradeoff  for  this  is  having  a  system  that  does 
not  need  continuous  attention  of  the  operator. 

As  noted  in  chapter  V  the  ACV  and  TCV  used  essentially  the  same  host  system. 
This  means  both  systems  had  all  of  the  sensor  subsystems  attached.  This  meant  no 
tradeoffs  were  realized  with  the  TECHMAN  project.  However,  the  TCV  would  not  need 
the  color  sensors  or  ultrasonic  sensor  unless  the  user  detennined  it  was  still  useful  for  the 
operator.  If  the  sensor  were  removed  in  later  updates  of  the  system,  then  less  complexity, 
less  power  consumption,  and  reduced  weight  would  be  on  the  TCV  making  it  cheaper 
and  easier  to  maintain. 
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6.  What  are  the  impacts  both  with  acquisition  and  mission  completion  when 
comparing  autonomous  and  teleoperated  UGVs? 

Chapter  VII  that  covers  the  LCC  contains  the  time  and  cost  difference  between 
ACV  and  TCV  systems  as  related  to  acquisition.  Question  4  stated  the  autonomous 
system  required  an  additional  55  hours  and  cost  and  9.7%  more.  As  far  as  the 
JCIDS/DAS  process  is  concerned  the  TECHMAN  systems  did  not  find  any  differences  or 
impacts  other  than  the  additional  time  required  to  develop  the  systems.  All  of  the  same 
SE  processes  and  JCIDS/DAS  items  were  required  for  both  types  of  systems. 

Chapter  VI  has  the  evaluation  of  the  ACV  and  TCV  systems,  which  covers  the 
impacts  to  mission  completion.  The  main  take  away  is  it  would  depend  on  the  mission  as 
to  which  is  better.  If  the  mission  was  covered  exactly  as  written  in  the  DRM  then  the 
TCV  or  teleoperated  system  would  be  better  as  it  is  faster  and  more  accurate.  However,  if 
line  of  sight  is  not  available,  multiple  areas  need  cleared,  or  operators  are  not  able  to  give 
their  undivided  attention  to  the  system,  then  the  ACV  is  the  better  choice. 

7.  How  much  of  a  difference  does  the  choice  of  a  software  engineering  approaches 
make? 

Chapter  IV  that  has  the  AOA  and  chapter  V  that  covers  software  design  contains 
the  details  of  the  software  engineering.  This  question  is  difficult  to  answer  as  only  one 
software  approach  was  used  and  only  speculation  can  be  given  of  the  others.  The  main 
takeaway  is  developer  familiarly  made  the  largest  impact.  Using  approaches  and  tools  the 
developers  were  familiar  with  cut  down  on  learning  time  and  allowed  the  developers  to 
better  explain  the  software  design  to  the  other  members  of  the  team. 

C.  RECOMMENDATIONS  FOR  UGVS  WITHIN  JCIDS/DAS 

Part  of  the  project  team’s  goal  was  to  make  recommendations  for  the  JCIDS/DAS 
process  or  UGVs  with  in  the  DOD.  The  initial  background  research  pointed  to  the  issue 
with  UGVs  was  that  they  used  rapid  fielding  processes  instead  of  the  JCIDS/DAS.  After 
performing  this  project  and  going  through  the  simulated  JCIDS/DAS  process,  the  team 
detennined  that  the  JCIDS/DAS  process  is  ideal  for  developing  not  only  a  system  but 
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also  necessary  infrastructure  to  support  that  system.  The  process  would  take  longer  than 
going  the  rapid  route  due  to  extra  requirements  and  more  design  iterations.  However, 
going  through  these  extra  steps  would  ensure  the  system  being  fielded  would  meet  the 
user’s  need. 

The  team  did  not  develop  any  recommendations  for  the  JCIDS/DAS  process 
itself.  The  team’s  recommendation  was  that  more  programs  should  go  through  the 
process.  Even  though  there  may  be  a  desire  to  cut  corners  and  field  a  system  faster  and 
cheaper,  it  only  hurts  the  DOD  in  the  long  run.  The  various  components  of  JCIDS/DAS 
do  add  value  to  the  overall  program. 

In  regards  to  recommendations  to  UGVs,  the  project  team  gained  some  interesting 
insight.  As  covered  in  the  report  the  team  developed  the  user  need  from  an  actual  ICD. 
However,  using  the  Lego  Mindstonns  kits  required  the  user  needs  and  requirements  to  be 
fulfilled  in  a  manner  limited  to  the  available  technology.  While  developing  the 
requirements,  many  discussions  took  place  on  how  several  of  the  requirements  could 
actually  be  modified,  giving  the  TECHMAN  system  a  chance  to  meet  the  requirements. 
The  insight  gained  is  there  is  a  balancing  act  with  requirements  and  capabilities. 
Requirements  may  need  to  be  iterated  such  that  technology  available  or  nearly  available 
can  meet  them  while  also  meeting  the  needs  of  the  user  and  pushing  the  performance 
envelope. 

Other  insights  are  more  obvious  ones  and  were  encountered  as  problems  during 
the  project.  One  of  those  is  that  requirements  need  to  be  clear  and  easy  to  understand. 
Knowing  this  trait,  even  while  developing  requirements,  the  team  still  had 
misunderstandings  when  developing  the  robots  later  in  the  project.  Another  insight  is  that 
requirements  should  be  changed  as  little  as  possible,  especially  after  the  systems  have 
been  developed.  Changing  the  requirements  late  in  the  program  can  increase  cost  and 
schedule.  However,  not  changing  requirements  means  the  original  requirements  must  be 
well  written  and  cover  all  the  user’s  needs  and  not  be  beyond  available  technology.  The 
TECHMAN  requirements  needed  minor  changes  after  the  initial  prototype  systems  were 
constructed.  The  change  was  made  because  to  the  technology  of  the  simulated  systems 
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could  not  meet  the  tougher  requirement.  After  the  requirement  was  changed  the 
autonomous  system’s  software  had  to  be  updated  to  account  for  the  new  requirements. 
This  added  time,  and  if  this  were  a  real  project,  it  would  have  added  cost  to  the  project.  If 
the  original  requirements  were  written  according  to  the  capabilities  of  the  existing 
technology  then  this  problem  would  not  have  been  encountered. 

D.  SUMMARY 

Project  TECHMAN  used  the  JCIDS/DAS  process  to  develop  a  teleoperated  and 
an  autonomous  UGV  system  with  the  capability  to  clear  an  area  of  small  containers.  The 
system  was  developed  through  the  Material  Solution  Analysis  Phase  to  MS  B.  The  team 
used  SE  tools  to:  define  a  mission,  develop  a  user  need,  develop  requirements,  develop 
the  system  architecture,  design  and  build  an  actual  system,  test  the  system,  evaluate  the 
test  results,  and  perform  a  LCC  analysis.  The  TECHMAN  system  was  successful  and 
able  to  complete  the  clearance  mission.  Through  research  and  practical  application  found 
during  the  development  of  TECHMAN,  the  team  learned  that  rigorous  JCIDS/DAS 
process  is  ideal  at  ensuring  the  developed  system  will  fulfill  the  user’s  need  and  be 
maintainable  throughout  the  systems  life-cycle.  The  team  also  discovered  that 
maximizing  the  clarity  of  requirements  initially  while  minimizing  any  changes  to  those 
requirements  later  increases  the  chances  of  a  successful  project. 
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APPENDIX  A:  TCV  SOFTWARE  INNOSLATE  ACTION  DIAGRAM 


Figure  49.  TVC  Software  Innoslate  Action  Diagram 
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APPENDIX  B:  ACV  SOFTWARE  INNOSLATE  ACTION  DIAGRAM 
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